Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Mar 18, 11:13=A0pm, "Marty Ryba" <martin.ryba.nos...@verizon.net> wrote: > Hello everyone, > > =A0 =A0 After banging our heads for last few weeks (sometimes literally), = I > figure I'll query the group of experts here. We have a design that is > functionally correct (ModelSim test bench) but it appears to be very iffy > when it gets on the real chip. I have a couple copies of "identical" board= s > with Virtex2-1000 chips on them. I'll check again soon, but I believe they= > are -6 parts. We've been synthesizing the design in Synplify Pro (v7.5 > though others are available; this design has some history of working fine)= . Which design are you referring to here that has some history of working fine? The PCB design or the FPGA design? > Sometimes it works on one or more boards, other times after I load it (and= > verify) with iMPACT this counter acts screwy (it messes up critical timing= , > and it also looks all wrong on Chipscope). You might want to clarify what you mean by 'messes up critical timing' and 'looks all wrong'. I'm assuming here that the counter starts off correctly and just doesn't decrement properly which would lead one to suspecting problems related in some way to the signal 'making_data' but again you should clarify this. In any case, the problem is one of the following (not in any particular order): 1. Inadequate power supply. Check the Vcc at the chip with a high speed scope and good probing techniques, make sure that you're within spec. If only 'slightly' out that's not likely the cause of your symptoms but is still something that needs to be addressed. 2. Timing. Are the signals 'RESET', 'counter_load' and 'making_data' all synchronized to 'CLK'? As I said, I'm not sure which symptoms you're exactly seeing but I'm guessing that it resets and initializes properly it's just not counting correctly in which case 'making_data' is the likely culprit. 3. More timing. There is more to timing than just clock frequency. There are also setup/hold time requirements. Do 'counter_load' or 'making_data' come from external I/O pins? If so, then - Do the signals on the board meet the timing requirements that you specified? - You did specify a timing requirement on the inputs? - Did the computed setup time from the P&R timing report (not Synplify's estimated timing) meet all requirements? 4. Yet more timing. 'CLK' isn't a gated clock is it? 5. Clock signal quality. Put a scope on the input clock. Is it absolutely monotonic through the entire Vih voltage range? Both edges? No dips and bounces anywhere between Vih(min) and Vih(max)? Go through the above checklist and I'm fairly confident that you'll find the cause. > We > tried trimming the size of the counter from 32 bits down to 20 and it seem= s > to help some. > This is a symptom of failing timing, see items #2, 3 and 4 or double clocking , see item #5 above. > > Another process block checks that this counter is nonzero and a few other > requirements to set the value of making_data true or false. > This is a process block that is clocked by 'CLK' I presume? How about the inputs into that process block? The same sort of timing considerations mentioned previously apply here as well. Violating timing may cause 'making_data' to miss or double hit occasionally. > > I notice the RTL shows this using an adder (it fans out making_data to > COUNT_WIDTH bits so that it becomes either the 0 or -1 to add). Isn't ther= e > a simpler structure to define a count(down) counter? I sure can buy a simp= le > counter in 74xx series logic. I notice neither arith_std or numeric_std > define special operators (a la C's ++ and -- operators) to specify > increment/decrement, so maybe there is no simple way to create a counter > structure in fewer FPGA logic elements. Seems odd to me (non-EE). > The RTL viewer is a graphical view of your SOURCE code, it is not a view of the final routed design. Have no fear, the adder that adds -1 and the muxer that selects the final output will get optomized appropriately. Good luck Kevin JenningsArticle: 130276
On Wed, 19 Mar 2008 03:13:40 GMT, "Marty Ryba" <martin.ryba.nospam@verizon.net> wrote: >Hello everyone, > > After banging our heads for last few weeks (sometimes literally), I >figure I'll query the group of experts here. We have a design that is >functionally correct (ModelSim test bench) but it appears to be very iffy >when it gets on the real chip. >the timing is marginal for a specified clock of 100 MHz around this path, >but the chip is really running at 66 MHz (PCI clock). One thought: Are you using anything like a DCM or (since it's a Virtex) DLL to clean up the clock? PCI clock can be stopped, and switched between 33 and 66 MHz, during a PC's boot sequence (I have watched this in a scope). This can confuse a DLL; you may need means to reset it after any such change; or use an alternative (constant frequency) clock. - BrianArticle: 130277
ratztafaz <heinerlitz@googlemail.com> wrote: >Will the 10th edition of ISE, to be relealed next week, finally >support multithreading/SMP machines to reduce synthesis + P&R time? >Will we finally get support for synthesis of System Verilog >constructs? >What other major features to you still miss? - Discuss! * Proper exit codes upon failure.. * Use libusb (drop jungo). * Published API for Impact. * GUI that doesn't crash. * Possible to exploit server farms such that the Synthesis/P&R can be shared between physically different machines. * Installer that allows installation on non-RH machines.Article: 130278
Hi, everyone. Do you think that the best way of doing this is to compute the clock period based on the Fmax information? I know that it's not exactly the same of finding the critical delay of my circuit, but I can't think of another way. What do you think of it? Guilherme Corr=EAa. On 19 mar, 00:25, Guilherme Corr=EAa <gcor...@gmail.com> wrote: > Hi, Rob. > > Thanks for answering. > Actually, I can't use the Classic Timing Analyzer. I need to use the > data obtained from TimeQuest, which is recommended by Altera for CMOS > 65nm projects. > > Guilherme C. > > On 19 mar, 00:20, Rob <buz...@leavemealone.com> wrote: > > > You can tell Quartus to use the Classic Timing Analyzer by going into > > the Timing Analysis Settings. > > > Guirico C. wrote: > > > Hello, > > > > I'm trying to identify the critical path of a sequential circuit using= > > > the TimeQuest Timing Analyzer. However, I'm facing some dificulties > > > because the tool doesn't provide, as the Classic Timing Analyzer used > > > to do, any table showing the worst-case paths of the circuit. Instead,= > > > the TimeQuest generates a table with the Required Width, the Actual > > > Width and the Slack refering to the pulse. > > > How can I find, based on this provided information, the critical delay= > > > of the circuit? > > > > Thanks a lot. > > > Guirico C.Article: 130279
u_stadler@yahoo.de wrote:
> thanks for all the answers!
> just tried it and yes it works in ise too!
Thanks for reporting the results.
-- Mike Treseler
Article: 130280"Antti" <Antti.Lukats@googlemail.com> skrev i meddelandet news:b2a2d8ca-444d-4508-9f2c-33adb30c8829@p73g2000hsd.googlegroups.com... > Hi > > I have been think and part time working towards a goal to make useable > and useful serialized processor. The idea is that it should be > > 1) VERY small when implemented in any modern FPGA (less 25% of > smallest device, 1 BRAM) > 2) be supported by high level compiler (C ?) > 3) execute code in-place from either serial flash (Winbond quad speed > SPI memory delivers 320 mbit/s!) or from file on sd-card > You mean a COP800 FPGA core :-) > serial implementation would be smaller and run at higher speeds, so > 128 clock per machine cycle would already mean 2 MIPS, what would be > acceptable for many applications. > The COP800 uses 10 clocks, Clock 1 = Precharge Clock 2-9 process 8 bits of data. Clock 10 ? > Parallax basic stamps I executes 2KIPS only, so ultra lite serial > processor in FPGA with 2 MIPS would be eh, for me its some to dream > off :) > > I have poked around this idea for some years, but never got the "final > kick" to really go and do-complete the design and development of this > processor. > > So I decided to offer some bounty for others to maybe motivate to work > for this goal and dream, current list of items available for the > developers from my own funding is listed here (I hope to add items and > maybe some $ by the time) > > http://code.google.com/p/serial-processor/w/list > > there is also very preliminary spec-goal document as well > > Antti Lukats -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic ABArticle: 130281
"austin" <austin@xilinx.com> wrote in message news:frolf3$ob81@cnn.xsj.xilinx.com... > > Other managers will ask about your schooling, grades, courses, etc. I > do not find that useful, as I know some of the best students become the > worst employees, and some of the worst students become the best > employees (education is required, but grades are not always a measure of > what you learned, nor how you may perform). > On the other hand, I've found idiots don't get top class degrees from universities with a good reputation. This is an important part of the information needed to determine if the candidate is up to the task. I find it useful. > > Xilinx is also about how you, the person, how you will fit and interact > with others here at Xilinx: how do you deal with difficult situations? > How do you argue a technical issue? How respectful are you of others, > and their diversity (we have employees from around the world working at > every site). > Out of interest, how many of the racist/mysogynistic/homophobic candidates that you've come across actually fess up to the fact that they hate the Welsh/Ellen DeGeneris/Ellen DeGeneris during the interview? > > How innovative are you? Are you able to "think out of the > box?" > > Good luck, > > Austin I wonder if 'waterboarding' would work as an interview technique? Probably illegal in a few states, perhaps the Xilinx jet could be used to carry the candidate overseas? Just thinking outside the box... Cheers, Syms. ;-)Article: 130282
On Mar 19, 8:38 am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Wed, 19 Mar 2008 03:13:40 GMT, "Marty Ryba" <martin.ryba.nos...@verizon.net> > wrote: > > >Hello everyone, > > > After banging our heads for last few weeks (sometimes literally), I > >figure I'll query the group of experts here. We have a design that is > >functionally correct (ModelSim test bench) but it appears to be very iffy > >when it gets on the real chip. > >the timing is marginal for a specified clock of 100 MHz around this path, > >but the chip is really running at 66 MHz (PCI clock). > > One thought: Are you using anything like a DCM or (since it's a Virtex) DLL to > clean up the clock? > > PCI clock can be stopped, and switched between 33 and 66 MHz, during a PC's boot > sequence (I have watched this in a scope). This can confuse a DLL; you may need > means to reset it after any such change; or use an alternative (constant > frequency) clock. > > - Brian My experience agrees with the common wisdom that it's almost always clocks or power. But sometimes in mysterious, non-obvious ways :-) Basic things to check on the timing side: - how do you *know* that this is the process that's giving you trouble? I'm assuming that there's a lot more logic than that in a V2-1000 :-) Step back and ask yourself why you're so sure this is the culprit. - do you know that the clock is OK inside the chip? Have you brought the clock out to a pin (or even a divide-by-two or by-four version, using a simple flop, *not* a DCM/DLL) and scoped it out? - are any of the signals in the process generated or used by a different clock? If so, fix that first, and make sure any clock crossing logic is (1) designed right, and (2) laced with do_no_replicate and do_not_retime synthesis attributes (details differ by synthesis tool) - Xilinx DLLs and DCM tend to exhibit peculiar behaviour in that their LOCK output can assert even though the output clock is completely unstable, or possibly just running at a harmonic, like half-rate. If you are using one of these devices, you need to manually implement your own "LOCK" output, in a frequency measurement module using a pair of counters, one from DCM and one from a known rock-solid (XTAL input) reference and verifying that they count up at the right rate relative to each other. Otherwise you need to keep hitting them with a reset. Then once everything else is stable, reset the rest of the chip. This problem can happen when input clocks are changed, as Brian mentioned, and can be made worse if you have a cascade of DLL's, depending on each other, producing a series of clocks. - do you have enough synthesis constraints on the clock and any pin inputs that may drive signals going into the state machine? - have you tried running a post-place-and-route timing annotated simulation to see if any timing errors show up there? Good luck, - KennArticle: 130283
Hi I'd like to share with you my experience concerning DDR SDRAM interface development for XUP V2P baord, it may save your time and money. I spent long time working on it, trying to make the code gererated by the older MIG tools working. I found that there's more other people with similar problem, but finally didn't get answer. Since I got new board, Spartan3a Starter Kit, everything works fine. Here's my advice - if your project requires more memory and you're not well experienced FPGA engineer, I strongly recommend Spartan3a (in fact DDR2 in this case) with ISE 9.2. RobArticle: 130284
> * Use libusb (drop jungo). Theres a much better approach availlable: XILINX JTAG tools on Linux without proprietary kernel modules windrvr sucks! look: http://www.rmdir.de/~michael/xilinx/Article: 130285
ratztafaz <heinerlitz@googlemail.com> wrote: > > * Use libusb (drop jungo). > Theres a much better approach availlable: XILINX JTAG tools on Linux > without proprietary kernel modules > windrvr sucks! > look: http://www.rmdir.de/~michael/xilinx/ You both mean the same... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 130286
On Mar 18, 8:13=A0pm, "Marty Ryba" <martin.ryba.nos...@verizon.net> wrote: > Hello everyone, > > =A0 =A0 After banging our heads for last few weeks (sometimes literally), = I > figure I'll query the group of experts here. We have a design that is > functionally correct (ModelSim test bench) but it appears to be very iffy > when it gets on the real chip. I have a couple copies of "identical" board= s > with Virtex2-1000 chips on them. I'll check again soon, but I believe they= > are -6 parts. We've been synthesizing the design in Synplify Pro (v7.5 > though others are available; this design has some history of working fine)= . > Sometimes it works on one or more boards, other times after I load it (and= > verify) with iMPACT this counter acts screwy (it messes up critical timing= , > and it also looks all wrong on Chipscope). Today I got brave enough to loa= d > it into the EEPROM; it worked this afternoon but who knows tomorrow (grrr)= . > Looking at the Synplify timing report (with -4 speed setting in Synplify),= > the timing is marginal for a specified clock of 100 MHz around this path, > but the chip is really running at 66 MHz (PCI clock). The key code is very= > simple (some syntax may be a bit off since I'm doing it from memory). We > tried trimming the size of the counter from 32 bits down to 20 and it seem= s > to help some. > > signal my_counter : std_logic_vector(COUNT_WIDTH-1 downto 0); > > countdown_process: process (CLK) > begin > =A0 if rising_edge(CLK) then =A0 =A0 =A0 =A0-- do everything synchronous > =A0 =A0 if RESET =3D '1' then > =A0 =A0 =A0 =A0my_counter <=3D ZEROIZE_COUNT; > =A0 =A0 elsif counter_load =3D '1' then > =A0 =A0 =A0 my_counter <=3D input_bus(COUNT_WIDTH-1 downto 0); > =A0 =A0 elsif making_data =3D '1' then > =A0 =A0 =A0 my_counter <=3D my_counter - '1'; > =A0 =A0 endif > =A0 endif =A0-- CLK > end -- process > > Another process block checks that this counter is nonzero and a few other > requirements to set the value of making_data true or false. > > Ideas/suggestions? My main FPGA engineer has been working with the local > Xilinx FAE but no "Eureka!" moments yet. A very similar (if anything, > somewhat larger) design has never shown this trouble on the same boards. T= he > current design takes about 45% of the LUTs. > > I notice the RTL shows this using an adder (it fans out making_data to > COUNT_WIDTH bits so that it becomes either the 0 or -1 to add). Isn't ther= e > a simpler structure to define a count(down) counter? I sure can buy a simp= le > counter in 74xx series logic. I notice neither arith_std or numeric_std > define special operators (a la C's ++ and -- operators) to specify > increment/decrement, so maybe there is no simple way to create a counter > structure in fewer FPGA logic elements. Seems odd to me (non-EE). > > Thanks in advance for your sagacity. > > -Dr. Marty Ryba > Mad GNSS scientist Marty, for the past 15 years, all Xilinx FPGAs have had a built-in ripple-carry structure which assures that a counter takes only one flip-lop per bit, up to 32 bits and beyond. If I were you, I would test this counter with a clean clock and adjust the clock frequency up until the counter fails. That should eliminate (or illuminate) the alleged frequency dependence. If your clock comes from PCI, then you should be very leary about running it through a DCM, which inherently does not tolerate abrupt frequency changes or excessive jitter. But the raw counter itself is very forgiving. Peter Alfke, XilinxArticle: 130287
>I wonder if 'waterboarding' would work as an interview technique? Probably >illegal in a few states, perhaps the Xilinx jet could be used to carry the >candidate overseas? Just thinking outside the box... Vomit comet(tm) ..? :-)Article: 130288
On Mar 18, 9:03 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
> Marty Ryba wrote:
> > Another process block checks that this counter is nonzero and a few other
> > requirements to set the value of making_data true or false.
>
> > Ideas/suggestions?
>
> Combine the two processes into one.
>
> -- Mike Treseler
Mike is spot-on here. In my experience, the comparison(s) is (are)
the problem, not the counter operation.
You need to be a little clever and predict when the counter will be
zero (or whatever):
elsif making_data = '1' then
my_counter <= my_counter - '1';
if my_counter = "0001" then -- If it's one, and we're
counting down
will_be_zero <= '1'; -- It will be zero by the time we
latch this
endif
Hope that helps,
G.
Article: 130289On Mar 18, 8:15=A0pm, "Guirico C." <gcor...@gmail.com> wrote: > Hello, > > I'm trying to identify the critical path of a sequential circuit using > the TimeQuest Timing Analyzer. However, I'm facing some dificulties > because the tool doesn't provide, as the Classic Timing Analyzer used > to do, any table showing the worst-case paths of the circuit. Instead, > the TimeQuest generates a table with the Required Width, the Actual > Width and the Slack refering to the pulse. > How can I find, based on this provided information, the critical delay > of the circuit? > > Thanks a lot. > Guirico C. Hi Guirico, The TimeQuest timing analyzer reports only a summary of the timing results by default during a full compilation. This is the worst-case slacks per clock domain in the reports ending in "Setup Summary", "Hold Summary", etc. found in the .sta.rpt file or in the messages. You can also enable the option "Report worst-case paths during compilation" in the timing analysis settings to see the worst-case path per clock domain by default. To see more paths, open the TimeQuest timing analyzer GUI and use "Report Timing" to report more paths. There are many other options available as well. For more information on the TimeQuest timing analyzer, please visit www.altera.com/timequest. Hope this helps, Subroto Datta Altera Corp.Article: 130290
On 18 mar, 12:41, KJ <kkjenni...@sbcglobal.net> wrote: > Google for lpm_fifo_dc and then ask Xilinx why they don't support EIA > standard LPM 220 components. > > KJ Very interesting, thank you. My understanding is that source code was available a while ago (edif.org) but this doesn't seem to be the case anymore. Any idea where I could find some source code? PatrickArticle: 130291
On Mar 19, 11:16=A0am, ghel...@lycos.com wrote: > On Mar 18, 9:03 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > > > Marty Ryba wrote: > > > Another process block checks that this counter is nonzero and a few ot= her > > > requirements to set the value of making_data true or false. > > > > Ideas/suggestions? > > > Combine the two processes into one. > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike Treseler > > Mike is spot-on here. =A0In my experience, the comparison(s) is (are) > the problem, not the counter operation. > > You need to be a little clever and predict when the counter will be > zero (or whatever): > > =A0 =A0 =A0elsif making_data =3D '1' then > =A0 =A0 =A0 my_counter <=3D my_counter - '1'; > > =A0 =A0 =A0 if my_counter =3D "0001" then =A0 =A0-- If it's one, and we're= > counting down > =A0 =A0 =A0 =A0 =A0 will_be_zero <=3D '1'; =A0 =A0 =A0 -- It will be zero = by the time we > latch this > > =A0 =A0 endif > > Hope that helps, > G. More general, and from a hardware point of view: When the counter approaches zero, the most significant bits go to zero first, and it is only the least significant bits that determine the final count of zero. So most of the inputs to your big comparator of 32 bits are stable long before the zer0-count is reached. That means you can divide up, and even pipeline your 32-bit comparator. You might also be clever and detect underflow at the Most Significant bit, and avoid the detector AND gate alltogether (but after one additional clock pulse). Peter Alfke, XilinxArticle: 130292
Ulf Samuelsson wrote: > "Antti" <Antti.Lukats@googlemail.com> skrev i meddelandet > news:b2a2d8ca-444d-4508-9f2c-33adb30c8829@p73g2000hsd.googlegroups.com... > >>Hi >> >>I have been think and part time working towards a goal to make useable >>and useful serialized processor. The idea is that it should be >> >>1) VERY small when implemented in any modern FPGA (less 25% of >>smallest device, 1 BRAM) >>2) be supported by high level compiler (C ?) >>3) execute code in-place from either serial flash (Winbond quad speed >>SPI memory delivers 320 mbit/s!) or from file on sd-card >> > > > You mean a COP800 FPGA core :-) With the COP800 well past it's commercial life, what is the status of 'abandonware' C Compilers for it ? How small is a COP800 in fpga ? > >>serial implementation would be smaller and run at higher speeds, so >>128 clock per machine cycle would already mean 2 MIPS, what would be >>acceptable for many applications. >> > > > The COP800 uses 10 clocks, > Clock 1 = Precharge > Clock 2-9 process 8 bits of data. > Clock 10 ? Opcode execute ? With BRAM being cheap, and DATA SRAM being slow/relatively expensive, the core needs to use many registers well. Features like Bank swap, or register frame pointer aka Z8/XC166 etc. Also a Push NN/PopNN would avoid costly DATA ram thrashing. -jgArticle: 130293
On Mar 19, 2:31=A0pm, Patrick Dubois <prdub...@gmail.com> wrote: > On 18 mar, 12:41, KJ <kkjenni...@sbcglobal.net> wrote: > > > Google for lpm_fifo_dc and then ask Xilinx why they don't support EIA > > standard LPM 220 components. > > > KJ > > Very interesting, thank you. My understanding is that source code was > available a while ago (edif.org) but this doesn't seem to be the case > anymore. Any idea where I could find some source code? > > Patrick Altera (Sim model and synthesis) Synplicity (synthesis only) Lattice (synthesis only) ISE (synthesis only, .TDF files) And that's the rub when it comes to LPM, you can't always get simulation models from the various synthesis vendors even though they 'support' it. The resourceful designer though might see that using the same interface that LPM uses (i.e. generics and signals) would make for a good starting point for making their own...while grumbling to the suppliers about their lack of sim support for a standard that they 'support'...while they try to claim that 'their' fifo interface is somehow superior to some others....even though it's not, their implementation of a fifo might be better, but the interface TO the fifo is not. The other reality is that by making you jump through hoops with their various wizards that purport to 'help' they lock you into their stuff just a bit. KJArticle: 130294
On 19 mar, 15:45, KJ <kkjenni...@sbcglobal.net> wrote: > Altera (Sim model and synthesis) > Synplicity (synthesis only) > Lattice (synthesis only) > ISE (synthesis only, .TDF files) > > And that's the rub when it comes to LPM, you can't always get > simulation models from the various synthesis vendors even though they > 'support' it. The resourceful designer though might see that using > the same interface that LPM uses (i.e. generics and signals) would > make for a good starting point for making their own...while grumbling > to the suppliers about their lack of sim support for a standard that > they 'support'...while they try to claim that 'their' fifo interface > is somehow superior to some others....even though it's not, their > implementation of a fifo might be better, but the interface TO the > fifo is not. > > The other reality is that by making you jump through hoops with their > various wizards that purport to 'help' they lock you into their stuff > just a bit. > > KJ I found the source code that was available at edif.org through archive.org: http://web.archive.org/web/20031204114425/http://www.edif.org/lpmweb/more/vhdl.htm It looks like complete source code, I'm not sure what additionnal support I would need from vendors. It seems to me that I could just use lpm_fifo_dc from 220model.vhd. Am I missing something? PatrickArticle: 130295
The Virtex2Pro board is not recognised by the latest version of EDK (9.2i) If you want larger memory the V2P DDR memory interface requires specialist support. Digilent nor Xilinx will not give you a working example. Strongly suggest Spartan 3A board instead.Article: 130296
Hi, is it possible to read a checksum of a EPM7032S with Byteblaster an Max Plus II without having any information of how and what can be inside only for test the Jtag is ok? If yes how can i do? Thanks for any help MAX EPM7032SEPM7032SArticle: 130297
Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> wrote: >ratztafaz <heinerlitz@googlemail.com> wrote: >> > * Use libusb (drop jungo). >> Theres a much better approach availlable: XILINX JTAG tools on Linux >> without proprietary kernel modules >> windrvr sucks! >> look: http://www.rmdir.de/~michael/xilinx/ >You both mean the same... Yep. (I thought no-one would misunderstand the original message)Article: 130298
Jim Granville wrote: > >>I have been think and part time working towards a goal to make useable > >>and useful serialized processor. The idea is that it should be > >> > >>1) VERY small when implemented in any modern FPGA (less 25% of > >>smallest device, 1 BRAM) > >>2) be supported by high level compiler (C ?) > >>3) execute code in-place from either serial flash (Winbond quad speed > >>SPI memory delivers 320 mbit/s!) or from file on sd-card > >> > > > > > > You mean a COP800 FPGA core :-) > > With the COP800 well past it's commercial life, what > is the status of 'abandonware' C Compilers for it ? > How small is a COP800 in fpga ? > > > > >>serial implementation would be smaller and run at higher speeds, so > >>128 clock per machine cycle would already mean 2 MIPS, what would be > >>acceptable for many applications. > >> > > > > > > The COP800 uses 10 clocks, > > Clock 1 = Precharge > > Clock 2-9 process 8 bits of data. > > Clock 10 ? We have a COP8 compiler. The COP8 certainly fits the description because it original implementation was almost identical. 8051, Z8 and 6804 would also be on my historical short list. Walter..Article: 130299
Antti, my impression is that a subset of the 32 bit Transputers with a serial implementation would be the best tradeoff in terms of complexity and performance. The 3 element hardware stack and ALU would be very compact on the FPGAs and the instruction set would give you reasonable access to a block RAM (you don't want to write too much to a Flash and it is nice to avoid reading random data from it to keep the instruction stream flowing). Depending on how compatible it was (I wouldn't include the multitasking and message sending stuff) you would have these languages available for it: http://www.classiccmp.org/transputer/languages.htm A serial implementation of a classic RISC (like MIPS or DLX) would be somewhat more awkward, but it would be doable. A well known serial processor was the Motorola MC14500B, which is probably as simple as it can get - see VHDL at http://www.brouhaha.com/~eric/retrocomputing/motorola/mc14500b/ Sadly, it is far too simple and wouldn't do a good job for the applications you are probably interested in. Since you mentioned Basic Stamps, a very unorthodox approach would be to implement in hardware the virtual machine for TinyBasic, put the interpreter in a block RAM and have your Flash hold the source (or tokenized source) directly. Sorry about only giving advice instead of actual help, but you know how hard it is to find time for so many projects. -- Jecel
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z