FPGA utilisation & pinout...
26 views
Skip to first unread message
Chris McClelland
Mar 27, 2012, 12:22:25 PM3/27/12
to UMDKv2 Developers
I did some rough estimates of resource-utilisation in the FPGA. I did
this by looking at the ratio of utilisation on the Nexys2 (Spartan-3E
FPGA) after place-and-route for the basic FPGALink reference design[1]
versus the existing (PSRAM-based) umdkv2 VHDL, and extrapolating using
a similar ratio from the FPGALink reference design running on an LX9
FPGA. This gives a resource utilisation figure of a little over 11%
for the LX9.
The synthesis report for the existing umdkv2 VHDL on an LX9 FPGA
(place-and-route obviously fails because there's not enough I/O to
drive a PSRAM instead of an SDRAM) gives another data point, at 8%. In
general the synthesis resource utilisation estimate will be wildly
optimistic, but there you go.
So assuming the SDRAM controller is not orders of magnitude more
complex than the existing PSRAM controller, we're looking at resource
utilisation of between 10% and 15% for the current feature-set on an
LX9 FPGA. We could probably get away with using the cheaper-but-pin-
compatible LX4 FPGA, but for these prototypes I suggest keeping the
LX9 because it's not THAT much more expensive and gives us the freedom
to add more cool stuff when we can think of it.
This suggests that we will almost certainly have enough space in the
FPGA for what we need to do. So we could potentially just go ahead
with designing the schematic and layout, and send off for components
and PCBs on the assumption that we'll be able to get the SDRAM
controller written and to some extent tested while we wait. It's
obviously a riskier course of action, because there's a higher
probability of getting something wrong, but if all goes well we end up
with working boards much earlier.
To this end I have been trying to assign the pins from the FPGA in
preparation for the schematic work. I have done it with a rough
topography in mind, such that the PCB layout will require very few
vias, hopefully giving us a fairly solid ground-plane on the back of
the board:
https://github.com/makestuff/umdkv2/blob/master/SIGNALS.txt
I added the /CART_IN line as requested by Rafael, but I can't find any
reference to /M3 anywhere. There's one spare pin left on the FPGA for
this. Rafael - can you send us some links to info about /M3 please?
Chris
[1] https://github.com/makestuff/libfpgalink/blob/master/vhdl/TopLevel.vhdl
this by looking at the ratio of utilisation on the Nexys2 (Spartan-3E
FPGA) after place-and-route for the basic FPGALink reference design[1]
versus the existing (PSRAM-based) umdkv2 VHDL, and extrapolating using
a similar ratio from the FPGALink reference design running on an LX9
FPGA. This gives a resource utilisation figure of a little over 11%
for the LX9.
The synthesis report for the existing umdkv2 VHDL on an LX9 FPGA
(place-and-route obviously fails because there's not enough I/O to
drive a PSRAM instead of an SDRAM) gives another data point, at 8%. In
general the synthesis resource utilisation estimate will be wildly
optimistic, but there you go.
So assuming the SDRAM controller is not orders of magnitude more
complex than the existing PSRAM controller, we're looking at resource
utilisation of between 10% and 15% for the current feature-set on an
LX9 FPGA. We could probably get away with using the cheaper-but-pin-
compatible LX4 FPGA, but for these prototypes I suggest keeping the
LX9 because it's not THAT much more expensive and gives us the freedom
to add more cool stuff when we can think of it.
This suggests that we will almost certainly have enough space in the
FPGA for what we need to do. So we could potentially just go ahead
with designing the schematic and layout, and send off for components
and PCBs on the assumption that we'll be able to get the SDRAM
controller written and to some extent tested while we wait. It's
obviously a riskier course of action, because there's a higher
probability of getting something wrong, but if all goes well we end up
with working boards much earlier.
To this end I have been trying to assign the pins from the FPGA in
preparation for the schematic work. I have done it with a rough
topography in mind, such that the PCB layout will require very few
vias, hopefully giving us a fairly solid ground-plane on the back of
the board:
https://github.com/makestuff/umdkv2/blob/master/SIGNALS.txt
I added the /CART_IN line as requested by Rafael, but I can't find any
reference to /M3 anywhere. There's one spare pin left on the FPGA for
this. Rafael - can you send us some links to info about /M3 please?
Chris
[1] https://github.com/makestuff/libfpgalink/blob/master/vhdl/TopLevel.vhdl
Rafael Gama
Mar 28, 2012, 10:52:22 AM3/28/12
to umdkv...@googlegroups.com
So assuming the SDRAM controller is not orders of magnitude more
complex than the existing PSRAM controller, we're looking at resource
utilisation of between 10% and 15% for the current feature-set on an
LX9 FPGA. We could probably get away with using the cheaper-but-pin-
compatible LX4 FPGA, but for these prototypes I suggest keeping the
LX9 because it's not THAT much more expensive and gives us the freedom
to add more cool stuff when we can think of it.
Totally agreed.
This suggests that we will almost certainly have enough space in the
FPGA for what we need to do. So we could potentially just go ahead
with designing the schematic and layout, and send off for components
and PCBs on the assumption that we'll be able to get the SDRAM
controller written and to some extent tested while we wait. It's
obviously a riskier course of action, because there's a higher
probability of getting something wrong, but if all goes well we end up
with working boards much earlier.
Given the last results, I think we should make some more tests with our dev kits.
Unfortunately, I still have to build the interface to my kit.
To this end I have been trying to assign the pins from the FPGA in
preparation for the schematic work. I have done it with a rough
topography in mind, such that the PCB layout will require very few
vias, hopefully giving us a fairly solid ground-plane on the back of
the board:
https://github.com/makestuff/umdkv2/blob/master/SIGNALS.txt
Finally I took a look at the signals list.
Is it possible to leave /UDSW out of the signal list and rely only on /LDSW to get low byte writes and word (16 bits) writes?I I know that cartridges that must get writes from 68000 (like the ones that have save game option and Super Street Fighter II for the bank switching) rely only on the /LDSW signal. (I will try finding sources for this).
I added the /CART_IN line as requested by Rafael, but I can't find any
reference to /M3 anywhere. There's one spare pin left on the FPGA for
this. Rafael - can you send us some links to info about /M3 please?
I really don't remember where I've read about the /M3. Anyway, I will search for that.
I have some SMS (Sega Master System) cartridges, so I will try to enable the SMS mode on my megadrive in the next weekend.
So thats my TODO list for the next weekend:
1) Trying to make some /OE measurements.
2) Attach a SMS cartridge to the megadrive and enable the Mark III (sms) mode.
3) Work on the interface to my FPGA kit.
Chris
[1] https://github.com/makestuff/libfpgalink/blob/master/vhdl/TopLevel.vhdl
Chris McClelland
Mar 28, 2012, 11:24:16 AM3/28/12
to UMDKv2 Developers
> Is it possible to leave /UDSW out of the signal list and rely only on /LDSW
> to get low byte writes and word (16 bits) writes?
That's a good idea. We've still got one spare FPGA line though so I'll
> to get low byte writes and word (16 bits) writes?
leave it in for now, but if we run short of pins again, UDSW will be
the first to go!
> Given the last results, I think we should make some more tests with our dev
> kits.
can determine what's going on.
Chris
Reply all
Reply to author
Forward
0 new messages