6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Mar 29, 2024 9:18 am

All times are UTC




Post new topic Reply to topic  [ 609 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8 ... 41  Next
Author Message
PostPosted: Thu Oct 04, 2012 11:56 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Arlet wrote:
More important than the access time is the max clock frequency, both of the SRAM, and what you can manage to get done with the FPGA and on the board. At these frequencies, it will be challenging...

Arlet, I'm glad you posted. I am postulating here, so forgive my lofty goals if they are not attainable...

This 1900x1080 will be the most aggressive of timings. Right now I am confident of 720p timings for a HDMI interface board I mentioned before, maybe 1280x720, using the current 2M SyncRAM. I am trying to plan for the Mainboard as it will need to be finalized soon. Always taking into consideration of at least 1 frame buffer in the SyncRAM... I would very much like to squeeze every last bit of performance from the $130+ 4M SyncRAM IC, if we were to head in this direction. I am a "Cost No Object" type performance oriented hobbyist...

The v1.0h board would require a videoDAC of a higher speed grade than the current 140MHz grade. Aside from this, I'm thinking maybe a CPU core (90+MHz), or maybe multiple RGB ALU's (100MHz+), controlled by the 8-bit parallel interface. Can the internal FPGA FIFO can deal with these rates with a 180MHz pixel clock in your opinion?

EDIT: BTW, the GSi Technology pin for pin Cypress compatible SyncRAM datasheet is easier for me to read and understand than the Cypress parts' datasheet. These parts have interesting behavior, especially when compared to old-school ASyncRAM, as stated in the GSi Tech datasheet:"In Flow Through mode the device may begin driving out new data immediately after
new address are clocked into the RAM, rather than holding new data until the following (second) clock edge. Therefore, in Flow
Through mode the read pipeline is one cycle shorter than in Pipeline mode."

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 05, 2012 5:22 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
ElEctric_EyE wrote:
The v1.0h board would require a videoDAC of a higher speed grade than the current 140MHz grade. Aside from this, I'm thinking maybe a CPU core (90+MHz), or maybe multiple RGB ALU's (100MHz+), controlled by the 8-bit parallel interface. Can the internal FPGA FIFO can deal with these rates with a 180MHz pixel clock in your opinion?

The FPGA can certainly run parts at 180 MHz, but it may require some extra pipeline stage in the memory controller. Running the RGB ALUs at 180 MHz should be fairly easy, because they can be pipelined without compromising the results. Running a CPU at 90 MHz and interfacing to 180 MHz is unknown territory for me. I know how to do it with async dual port block RAM in between, but that will come at the cost of increased latency. I believe there are ways to combine synchronous 90 and 180 MHz clocks in the same design, but I've never done it before, and don't know how difficult it is.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 05, 2012 1:00 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
This is good then. As long as you are reasonably confident, after all the 4M and 2M SyncRAMs have the same pinout, with the addition of 1 address pin. I've already added this feature and the v1.0h design is ready. Now it is only a matter of $ for the board run. Looking like a few weeks unfortunately, unless business picks up here...

EDIT: BTW, do you think removing Reset from your 6502 core would speed it up appreciably? How about if removing Reset, and/or NMI and/or IRQ? Thinking about it more, I guess we would need to keep Reset for the vector to point to the program start.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 05, 2012 6:08 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
ElEctric_EyE wrote:
EDIT: BTW, do you think removing Reset from your 6502 core would speed it up appreciably? How about if removing Reset, and/or NMI and/or IRQ? Thinking about it more, I guess we would need to keep Reset for the vector to point to the program start.


No, the critical paths all run through the ALU. From memory to ALU is usually a long one. Maybe the ALU could be optimized differently for Spartan-6.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 05, 2012 8:10 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
Arlet, I think you once suggested a specific change to pipeline the zero detect... Now that we have a good test suite and you have a rdy-wobbler, could you implement, test and release that change?
That would be much appreciated!
Cheers
Ed


Top
 Profile  
Reply with quote  
PostPosted: Sat Oct 06, 2012 2:24 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
BigEd wrote:
Arlet, I think you once suggested a specific change to pipeline the zero detect... Now that we have a good test suite and you have a rdy-wobbler, could you implement, test and release that change?

Done


Top
 Profile  
Reply with quote  
PostPosted: Sat Oct 06, 2012 2:40 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
Great - thanks!


Top
 Profile  
Reply with quote  
PostPosted: Sat Oct 06, 2012 3:11 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Awesome, is someone running a speed comparison test?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Sat Oct 06, 2012 3:23 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
No, but when I was working on the cs4954 board, I had everything running comfortably at 100 MHz, including the core. The change helped a bit, but I don't recall exactly what the difference was.


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 08, 2012 1:09 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
For v1.0h I've decided to add 4 pushbuttons which will fit on the backside of the MicroSD adapter. They will all be pulled high by a 4.7K resistor, when any of them are pushed. I will edit the constraint file to show the switch signals.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 08, 2012 1:28 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
If you have some space, I'd also recommend adding a few test points, like these, with a resistor + LED attached to each test point. That way you can provide a simple debug/status indicator through the LEDs, and attach a scope probe at the same time.


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 12:27 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Arlet wrote:
If you have some space, I'd also recommend adding a few test points...

I have avoided LEDs in this project, and anything else that may add inductance or any other possibility of noise. This v1.0g design takes successive hi-speed signals from previous boards, potentially at 108MHz. What' I've been doing for pin testing, is to cut about 4" length of .015" diameter WireWrap wire and wrap it around the scope probe and then test desired pins. Clearance is tight and requires a steady hand, but this works.

Now, if this were a BGA design, I can see how bringing out some pins as you've suggested, may help in troubleshooting...

EDIT: Corrected top MHz.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Last edited by ElEctric_EyE on Tue Oct 09, 2012 10:46 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 5:58 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
You don't have any low speed signals that you can hijack for this purpose ? Something going to serial flash, or something like that.


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 2:25 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Why would you want to do this? or maybe which signals would you want to look at in particular? I could surely put in some holes to accomodate the test points, however there are only 3 holes left in v1.0h design.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 09, 2012 2:37 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
ElEctric_EyE wrote:
Why would you want to do this? or maybe which signals would you want to look at in particular? I could surely put in some holes to accomodate the test points, however there are only 3 holes left in v1.0h design.

To make it easier to put a scope probe on a signal, and keeping your hands free at the same time. Holding a probe stable on a 0.5 mm pitch pin while fiddling with the knobs, or a second probe isn't very easy. The exact signals depends on thing I'd like to look at. The advantage of the FPGA is that you can bring out any signal (even a duplicate of an existing one) to any of the pins. For instance, if there's a weird problem that only happens once per second, you can try to create a trigger expression, and bring out that trigger signal to a test pin so you can capture it on the scope while probing any of the other signals at the same time.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 609 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8 ... 41  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: