"Alessandro" <apoppi@email.it> wrote in message 
news:ga6lv4$e0a$1@aioe.org...
> Take a look at this waveforms, captured on real hardware (my xilinx 3E

Thanks for that, and the write up. You're having way more fun than I am this 
moment.

>> I think I saw 10ns 1Mx8 TSSOP SRAM not very long ago for < $20. A
>> quick look through DigiKey should answer that pretty quickly.
>
> I think I may go on both sides. I think I will find a PQ208 board and add 
> a static ram, but I'd also like to experiment with the psdram on the 
> nexys2. I will probably be seeking for both.

I recall now where and why I was shopping that. Avnet sells a great little 
$40 card with an S3-400A and PSOC/USB2. It doesn't come with any RAM, and 
not enough I/O on the headers if I put the memory there. It might be worth a 
quick look for your needs. The price would be unbeatable if you can fit 
inside its pin budget.

On Tue, 9 Sep 2008 21:49:03 +0200, "Alessandro" <apoppi@email.it>
wrote:

|james wrote:
|
|> Add $20 tothe base price and you get a XC3S1200 instead of the XC3S500
|> onthe NEXYS 2 board. Then you will have more than enough room for a
|> dual port SDRAM controller. I would still believe that the ZX would
|> fit well into the XC3S500 with a dualport SDRAM controller.
|
|I took a look at the micron psdram's datasheet; I suppose a dualport sdram 
|controller is a piece of logic that translates an asynchronous access 
|(microprocessor side) to a synchronous one (ram side).
|
|---------

A dual port SDRAM controller will allow two outside devices/processes
access to the same ram ie, microprocessor and video processor or what
other device that needs access to memory. The interface to each port
can be very simple or even made to look as if the device/process is
accessing static ram. All depends on how much code you want to write
and above and beyond thebasic SDRAM controller. 

  
|You're not talking about using the blockram as a dualport cache, are you?

No.

james

Alessandro wrote:
> 
> :-) Now I've got the point. If I could have 64KB of bram, then the problem 
> would be solved at least for "normal" use. Unfortunately this amount is only 
> available on the 1600K gates chip. The reason for having a 21MHz zx-spectrum 
> is, for example, ResiDOS which runs pretty fine on my cpld-based version of 
> the clone, now being ported to fpga.

Let's see. The real Spectrum (used to) run at 3.5 MHz CPU clock, so one 
cycle is ~286 ns. Z80 never uses 2 consecutive clocks for data access, 
so SOME memory could operate at full speed. Now the memory shared with
video had to use wait states. Actually as I recall the clock "stopped"
for a while. Anyway many programs tried to put code that needed fast
execution into the non-contended area.

You want to use 21 MHz clock.  47 ns. Considering at least 2 cycles for
a CPU access, 70 ns PSDRAM should work fine. Use BRAM for video memory-
you only need 32K.


I have my own FPGA based Spectrum clone, that's why this info is 
relatively fresh in my memory.

See
http://mirrow.com/FPGApple/revisited.html

Full source is there too. Built for Altera DE1 board, but all portable 
Verilog.


> 
> Anyway, yes... maybe I can slow it down a little. The other point was having 
> not to deal with some complex and/or critical technology (and difficult 
> packages) so that an hobbyst could assemble it's own machine, so a PQ208 and 
> a static ram seemed nice.

I'm kind of a professional, but I'd rather not try to solder PQ208 
chips. Last time I tried an 80 pin 0.5 mm pitch one I failed miserably.
Obviously other people have better skills at this, but IMHO for the 
majority using an inexpensive off-the-shelf board would be a huge benefit.



> 
> Ciao!
> Alessandro
> 
> 

MikeWhy wrote:

> Actually, I wasn't aware of that; thought it was DDR for some reason.
> CL3 SDR at 80 MHz does seem a bit challenged, maybe not even viable.
> I see they publish a Verilog simulation model. Might be interesting
> to see what speed you can get out of the processor. Do what you can
> with caching and bursts. Some stalling seems inevitable with any
> memory architecture.

...but I see there is a 'busy' line which could be fed to the micro and halt 
it sometimes (if not too frequent). It seems it could happen in case of 
refresh and access collision (from the psdram installed on the nexys2 
datasheet).

> Instruction and data on the same bus, 43 MHz, same cycle r/w? Would be
> challenging even for DDR2 at 133 MHz, I think.

Not so tight. On the current version of the T80 code, only the opcode fetch 
needs a pretty fast response from memory. Having to accomodate both the 
memory access and memory refresh cycles (Z80 does that), mreq and rd or wr 
only lasts for one T-state (one clock cycle).

I think there is a way to disable the memory refresh cycle (which is simply 
a waste of time) but this will require some bugfix to the core itself (in 
the first version I downloaded from opencores, there is a bug which turns it 
into a super-Z80 with one cycle memory and I/O access and there is no way to 
slow it down). One of the project maintainers provided the solution already 
used on www.fpgaarcade.com for the pacman project (an alternate wrapper). 
Now timings are ok, except for the opcode fetch which on a real Z80 takes 
almost 2,5T-states in place of 1.

Take a look at this waveforms, captured on real hardware (my xilinx 3E 
evaboard) while the processor of the zx-badaloc (T80) was performing an OUT 
($FE),A with A = 7 (from the zx-spectrum rom, power-on initialization, 
border color setup):

http://www.zxbada.bbk.org/out_fe-07.gif

Clock speed here is 3,5MHz (as on original sinclair hardware). Due to lack 
of pins on the hirose connector, address bus is only two bits wide and there 
is no input databus to the processor (only output is shown) but it's enough 
to understand what's going on.

Between markers A and B you can see the OUT instruction opcode fetch, which 
takes 4T-states (as original Z80). The difference is that mreq and rd are 
active for just one T-state in place of 2,5. At 21Mhz, this means that the 
memory should place valid data within about 35/40ns. The reminder of the 
cycle is the refresh cycle.

Then, the operand for the out instruction is read from the next memory 
location, showing a standard memory read access (markers B and C). This 
should (and does) take 3 T-states. Mreq and rd are active for 2T-states, so 
far easier for the memory to comply.

Markers C and D show the instruction execution. Since A holds 07, this value 
is placed on the output databus while iorq + wr goes active. It should be 
noted the advantage of having separate input and output databuses: data is 
held on the OUT databus after instruction completion, giving the device 
enough time to recognize the deactivation of iorq+wr, while the next 
instruction is being fetched from the IN side of the databus.

Here I suppose there is a little bug in T80, since an I/O access should last 
4 T-states in place of the three shown here, as Z80 places an extra wait 
state.

> I think I saw 10ns 1Mx8 TSSOP SRAM not very long ago for < $20. A
> quick look through DigiKey should answer that pretty quickly.

I think I may go on both sides. I think I will find a PQ208 board and add a 
static ram, but I'd also like to experiment with the psdram on the nexys2. I 
will probably be seeking for both.

Ciao!
Alessandro

Alex Freed wrote:

> The whole point of the SDRAM is that it takes a while to set up
> a read/write operation, but then a word is transfered on every clock.
> Perfect for a video controller when you want to read the whole line
> at once.

I see.

> I don't quite understand the point in making a ZX Spectrum operate at
> a high speed - you can't play the games and it's not exactly a perfect
> platform for doing anything serious enough to require high speed,
> but this is beyond the point. You can still use BRAM as cache. I
> suspect with a couple of 16K such blocks most programs will never
> have a cache miss :)

:-) Now I've got the point. If I could have 64KB of bram, then the problem 
would be solved at least for "normal" use. Unfortunately this amount is only 
available on the 1600K gates chip. The reason for having a 21MHz zx-spectrum 
is, for example, ResiDOS which runs pretty fine on my cpld-based version of 
the clone, now being ported to fpga.

Anyway, yes... maybe I can slow it down a little. The other point was having 
not to deal with some complex and/or critical technology (and difficult 
packages) so that an hobbyst could assemble it's own machine, so a PQ208 and 
a static ram seemed nice.

Ciao!
Alessandro

james wrote:

> Add $20 tothe base price and you get a XC3S1200 instead of the XC3S500
> onthe NEXYS 2 board. Then you will have more than enough room for a
> dual port SDRAM controller. I would still believe that the ZX would
> fit well into the XC3S500 with a dualport SDRAM controller.

I took a look at the micron psdram's datasheet; I suppose a dualport sdram 
controller is a piece of logic that translates an asynchronous access 
(microprocessor side) to a synchronous one (ram side).

You're not talking about using the blockram as a dualport cache, are you?

Ciao!

"Alessandro" <apoppi@email.it> wrote in message 
news:ga47np$am5$1@aioe.org...
> MikeWhy wrote:
>
>> Also take a look at Digilent's Nexys2
>> http://www.digilentinc.com/Products/Detail.cfm?Prod=NEXYS2&Nav1=Products&Nav2=Programmable.
>> $100 USD. Sounds like a good match except the FG320 package, 16 MB
>> SDRAM, and Xilinx platform flash. VGA output is 8-bit color only.
>
> I saw this board a couple of weeks ago. Maybe a good choice now that I 
> know that sdram is simpler to drive than the ddr. That kind of sdram, 
> furthermore, can be accessed a static ram (slow: 70ns).
>
> Do you think that the typical random access of an 8 bit microprocessor 
> could take advantage of the "sdram mode" over the 70ns "static ram mode"? 
> I mean, an average-design sdram controller could get more out of that chip 
> than 70ns in random rd/wr?

Actually, I wasn't aware of that; thought it was DDR for some reason. CL3 
SDR at 80 MHz does seem a bit challenged, maybe not even viable. I see they 
publish a Verilog simulation model. Might be interesting to see what speed 
you can get out of the processor. Do what you can with caching and bursts. 
Some stalling seems inevitable with any memory architecture.

Instruction and data on the same bus, 43 MHz, same cycle r/w? Would be 
challenging even for DDR2 at 133 MHz, I think.

I think I saw 10ns 1Mx8 TSSOP SRAM not very long ago for < $20. A quick look 
through DigiKey should answer that pretty quickly.

Alessandro wrote:
> 
> I saw this board a couple of weeks ago. Maybe a good choice now that I know 
> that sdram is simpler to drive than the ddr. That kind of sdram, 
> furthermore, can be accessed a static ram (slow: 70ns).

The whole point of the SDRAM is that it takes a while to set up
a read/write operation, but then a word is transfered on every clock.
Perfect for a video controller when you want to read the whole line
at once.

> 
> Do you think that the typical random access of an 8 bit microprocessor could 
> take advantage of the "sdram mode" over the 70ns "static ram mode"? I mean, 
> an average-design sdram controller could get more out of that chip than 70ns 
> in random rd/wr?

The controllers making SDRAM look like SRAM are very inefficient. They 
take 5-7 clocks for every word read/written. If you read consecutive 
words, it goes very much faster.

I don't quite understand the point in making a ZX Spectrum operate at
a high speed - you can't play the games and it's not exactly a perfect
platform for doing anything serious enough to require high speed,
but this is beyond the point. You can still use BRAM as cache. I suspect
with a couple of 16K such blocks most programs will never have a cache
miss :)


-Alex.

On Sun, 7 Sep 2008 23:24:22 +0200, "Alessandro" <apoppi@email.it>
wrote:

|I've also found  this interesting board 
|http://www.digilentinc.com/Products/Detail.cfm?Prod=NEXYS2&Nav1=Products&Nav2=Programmable 
|with 16MB of "cellular ram", or psdram, which can be accessed like an 
|asynchronous chip (self refresh is internally provided) but, unfortunately, 
|it's speed is 70ns in async mode.
|
|------------

Add $20 tothe base price and you get a XC3S1200 instead of the XC3S500
onthe NEXYS 2 board. Then you will have more than enough room for a
dual port SDRAM controller. I would still believe that the ZX would
fit well into the XC3S500 with a dualport SDRAM controller. 

james 

Frank Buss wrote:

> Use non-DDR SDRAMs in your design. I'm not sure, but I think there is
> no lower limit for the clock and you can implement your own SDRAM
> controller, which is easy, if you don't need the highest performance
> with burst-access, caching etc.

Ok, I think I see your point. It looks like worth of spending some time 
seeking for info about sdram world, if it's really easier than ddr.

I think I'll download an sdram datasheet (for example the psdram installed 
on the nexys2 board) to see if I could afford it and if the speed is 
comparable to that of a static ram chip. I think 15 or maybe even 20ns of 
"equivalent static ram" could be enough, if I can handle properly the T80 
signals in order to maximize the available time for the memory to respond. 
10ns would be really perfect but I don't think it's possible.

Thanks to everybody!
Alessandro