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
Years ago I did an XC3020 design for a universal smartcard controller that consisted of the
FPGA, a small PLD and a PROM. On boot up, the FPGA got loaded with a configuration designed to
wait for a smart card to be inserted, and then determine which interface that smartcard had,
then it would reboot itself with the appropriate design for communicating with that smart
card. When the smart card was removed, it would again reboot with the discovery program. The
FPGA also had a keypad controller, display driver, and serial comm that was common to all the
loadable designs. So, yes, an FPGA can reboot itself, although you may need a little bit of
external hardware to support it. The PLD in that case was a small one of the 22V10 style. I
don't recall which one was used, but it was the cheapest I could find that would support a PROM
big enough to hold the dozen or so FPGA bitstreams for all the smart card variations. The FPGA
basically wrote a pointer to the PLD, then the PLD pulsed the program pin and initiated the
reload starting at the pointer address. A cold start depended on the FPGA pins not being
driven (I think we had pulldowns on the vector lines)
To load via USB, you'll need the USB interface to stay alive, which means either an FPGA that
is partially configured or an external device. Partial configuration is currently a lot of
extra effort for a small gain thanks to the tools being not really ready for prime time.
Lasse Langwadt Christensen wrote:
> Antti Lukats wrote:
> > Marius Vollmer <mvo@zagadka.de> wrote in message news:<87ad3hp6w2.fsf@zagadka.ping.de>...
> >
> >>Imagine you want to have an FPGA board that has a USB port and no
> >>other connection (i.e., no other way to upload a bitstream). Can that
> >>FPGA bootstrap itself over the USB port?
> >>
> >>There would be a 'boot' bitstream in some flash on the board and the
> >>FPGA would be configured initially with that bitstream. The function
> >>of that bitstream would be to make the FPGA listen on the USB port for
> >>another bitstream that is then used to configure the FPGA for its real
> >>function.
> >>
> >>Can this be done? Without external memory (other than the boot
> >>flash)?
> >
> >
> > YES. but it is a little bit dangerous as the FPGA would rewrite the main
> > primary config and if the process is not succesful the system will be
> > totally dead.
> >
> > Altera Cyclone: doable with no tricks.
> > Atmel FPSLIC: use I2C port to repropgram the config memory appnote exists.
> > Xilinx: connect config memory JTAG to FPGA
> >
> > antti
> > www.openchip.org
>
> you could use one of the usb-serial/usb-parallel chips from ftdichip.com
> they have a bigbang mode that when connected to the config pins on the
> fpga could configure it, you won't even need a prom then.
> I haven't figured out if theres a smart way use all of the interface
> pins on the FTDI and at the same time be able to reconfigure.
>
> Guess you could have some logic in the fpga to pull its own "program" pin
> with a command send over usb?
> it shouldn't care if the rest of the config pins a toggling after
> configuration?
>
> -Lasse
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 66401
As others have said, you can't sample the counter directly because doing
so is inevitably going to result in some samples grabbing some bits from
the previous count and some from the current count (due to sampling right
as the count advances), which will generate some corrupted count values
(consider the case where the counter goes from "01111111" to "10000000":
all the bits are changing.
There are several valid ways to attack this. One is using grey code so
that only one bit changes at a time where you cross the clock domains.
You can also use a holding register and semaphores, or use a small FIFO,
or ....
prav wrote:
> hi all,
>
> I have a counter running at 50 Mhz . Now i have to sample that counter
> at 77 Mhz.
>
> My question is can i sample the counter running at 50 mhz directly
> with 77 mhz clock or should i synchronize the 50 mhz counter to 77 mhz
> clock domain and then only sample it.
>
> what are the effects if i don't the sample the 50 Mhz counter and i
> directly sample with 77 Mhz.
>
> rgds,
> prav
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 66402
GSR is fed to all flip-flops. I'm afraid I may have mislead you by saying
you can check it in FPGA editor. All you can check there is the initial
values of the flip-flops. On configuration, every flip-flop is set to a
known value. Generally speaking, the default is '0' unless the flip-flop
has a set or preset input, in which case it is a '1'. What ROC does for
you is provide a simulation of the reset on configuration, and where the
initial value is not the default it sets the initial FF value. If it is
connected to all the flip-flops in your design, then the simulation will
match the hardware exactly. If it is not connected to all flip-flops in
your design, the ones that it is not conencted to will come out of
configuration with the default value in the hardware. The simulation of
that circuit will result in initial values of 'U' for any inferred
flip-flops that are not initialized by the roc component. You can also
have multiple ROC's in the design so that a global reset does not
necessarily have to be propagated to the top level of a design. For
simulation, it doesn't matter and for implementation, the mapper takes them
out before the multiple instances cause trouble.
One caution however, using a global reset with the ROC will also prevent
inference of flip-flops using the dedicated set/reset, so you won't get
inferred FDRE's or FDSE's. That can be an issue if you are trying to get
max density or performance. If you want those, you'll either have to
accept the default init state by forgoing the global reset (you can still
put the global reset in the code, but surround it with a syn_translate off
pragma so that the simulation matches the hardware) or instantiate the
appropriate primitive.
In summary:
The hardware comes up in a known state regardless of the presence of ROC.
ROC is a simulation primitive: in simulation, it generates a reset pulse
which puts all the attached FF's to a known state
ROC a place holder, it preserves the global reset in the netlist, which is
necessary to initialize any of the flip-flops in the non-default state,
but also blocks use of the FF's reset pin by the synthesizer (I think
synplify might have fixed that in 7.3.4)
You won't see a dedicated net for the global reset in FPGA editor, GSR is a
dedicated net connected to all flip-flops in the design. The only evidence
you'll see in FPGA editor is the application of the correct init values for
FF's with non-default init values.
rickman wrote:
> Nial Stewart wrote:
> >
> > I've built the design with the ROC module driving rst.
> >
> > In the floorplanner if I do a search for Net rst, highlight it then
> > look for all logic loading that net I get 491 flip flops.
> > There are 1372 slice flip-flops in the design, and many that
> > aren't loading rst are asynchronously reset in the code.
> > You can easily find flip flos in the floor plan that aren't
> > selected.
> >
> > I'm not happy this is doing what I want it to.
> >
> > When I use the counter reset mechanism as discussed
> > elsewhere in the thread and do a search for rst I
> > get 15 nets. Selecting these and doing a search for
> > then selecting logic loading these nets gives 1558 symbols,
> > and I can't see a flip_flop on the floorplan that's
> > not selected.
> >
> > I'll stick with this method unless I can work out why
> > the GSR implementation isn't working.
> >
> > Did Ray actually give advice that was wrong?
>
> I may be mistaken, but I thought that *all* FFs were *always* driven by
> the global reset signal. By specifying in your code the async reset,
> you can make the simulation match the chip and you can control whether
> the FF is set vs. reset.
>
> Am I mistaken about this? Can the chip remove the GSR from FFs? Maybe
> I am confusing the GSR which can be controlled by the user with a power
> on reset...
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design URL http://www.arius.com
> 4 King Ave 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 66403Nicky wrote: > > Thank you for your answer. > In the meanwhile I already read all the threads I could find in this > newsgroup concerning this topic. > > Your PCI-card is a universal card as well. In a 5V PCI slot the > Quickswithes transfer 5V to 3.3V in one direction and the other way > round in the other direction but what does the Quickswith do in a 3.3V > slot? In a 3.3 volt slot the quick switch conducts without affecting the signal appreciably. A 5 volt signal is limited (clipped) by the Vcc to the switch. The switch is not really doing a voltage translation. It just raises its resistance significantly when the signal voltage gets near Vcc. > And I have another question. Somewhere in a newsgroup message I read > that for universal PCI cards it is necessary to store 2 different > bitfiles in an EEPROM and configure the PCI-FPGA depending on the > voltage. That is to say 3.3V needs another configuration than 5V. Is > this true? If yes, why? Anyway I can't do that since I use a Lattice > FPGA which provides an internal EEPROM and my board is not going to > have an external one additionally. The difference between the two standards is not just voltage levels. The 3.3 volt bus *requires* internal diodes to Vcc to limit overshoot. On a 5 volt bus these would cause real problems since signals can swing above 3.3 volts normally. But if you are using the quick switches, the FPGA will not see the voltages above 3.3 volts no mater what the bus does. So you can live with one FPGA load. I am not sure how the quick switches perform compared to the spec. The fact that your card seems to work in a small system does not mean you are meeting spec or that it will work in a heavily loaded system. > I planed to use the PCI clock and put it into a PLL in the PCI-Core > Lattice and consequently distribute the PLL-generated clock to other > devices on my PCI card. I read that on your board the PCI-Clk is also > routed to a PLL and is available for user logic. However, I read that > this is maybe not a good idea since according to the PCI-spec it is > possible that the PCI-clk is 0-33 MHz. On the other hand with an > external oscillator there are much more problems with synchonisation. > How did you tread this problems? Does the Altera Cyclone provide > intern FIFOs with 2 different clocks? I don't know if the PLL inside the FPGA will do a good job of distributing this signal. This will require feedback from the output pin to align the output to the clock input. Standard clock chips will do a much better job of this. You will not find many PCI implementations that run the clock much below 33 MHz. But you will find some that jitter it to spread the EMI across a wider spectrum and lower the readings. I believe this is not extensive and is compatible with most PLLs, but you should verify this. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 66404
> We are in the process of completing a LZ based compression core that > is very similar to LZS, but does not violate the patents. The > performance in a Xilinx V2Pro is expected to be on the order of 100M > bytes/second, with a 512 byte dictionary. We expect to release this > core for Xilinx v2/v2pro/s3 and Altera Stratix by the end of March. Good info Erik. How does the above performance compare to a 2 or 3 GHz 64 bit processor? SteveArticle: 66405
Rick wrote - > >I don't know if the PLL inside the FPGA will do a good job of >distributing this signal. This will require feedback from the output >pin to align the output to the clock input. Standard clock chips will >do a much better job of this. > The PLLs in the Lattice device have selectable internal or external feedback, which will allow you to null out board level delays effectively. Works quite well. Michael Thomas LSC SFAE New York/New Jersey 631-874-4968 fax 631-874-4977 michael.thomas@latticesemi.com for the latest info on Lattice products - http://www.latticesemi.com LATTICE - BRINGING THE BEST TOGETHERArticle: 66406
On Wed, 18 Feb 2004 11:43:03 -0800, Lasse Langwadt Christensen wrote: > Antti Lukats wrote: >> Marius Vollmer <mvo@zagadka.de> wrote in message >> news:<87ad3hp6w2.fsf@zagadka.ping.de>... >> >>>Imagine you want to have an FPGA board that has a USB port and no other >>>connection (i.e., no other way to upload a bitstream). Can that FPGA >>>bootstrap itself over the USB port? >>> >>>There would be a 'boot' bitstream in some flash on the board and the >>>FPGA would be configured initially with that bitstream. The function >>>of that bitstream would be to make the FPGA listen on the USB port for >>>another bitstream that is then used to configure the FPGA for its real >>>function. >>> >>>Can this be done? Without external memory (other than the boot flash)? >> >> >> YES. but it is a little bit dangerous as the FPGA would rewrite the >> main primary config and if the process is not succesful the system will >> be totally dead. >> >> Altera Cyclone: doable with no tricks. Atmel FPSLIC: use I2C port to >> repropgram the config memory appnote exists. Xilinx: connect config >> memory JTAG to FPGA >> >> antti >> www.openchip.org > > you could use one of the usb-serial/usb-parallel chips from ftdichip.com > they have a bigbang mode that when connected to the config pins on the > fpga could configure it, you won't even need a prom then. I haven't > figured out if theres a smart way use all of the interface pins on the > FTDI and at the same time be able to reconfigure. > > Guess you could have some logic in the fpga to pull its own "program" > pin with a command send over usb? > it shouldn't care if the rest of the config pins a toggling after > configuration? > > -Lasse This is what our USB-JTAG programmer does. The FPGA config is downloaded to the FPGA via a FTDI USB245 in bit bang mode. A FPGA output bit can be asserted to set /PROGRAM if need be for reconfiguration (or The USB device can be put into suspend mode, this will power down the FPGA and allow re-configuration when brought out of suspend) Peter WallaceArticle: 66407
Here's an idea that I had. You'll have to be able to tolerate several clocks of delay though. 1) Run the output of the counter to a set of D flip-flops clocked at 50MHz so the counter is continuously sampled. 2) Take a signal from the 77MHz clock domain that indicates you want to sample the count and run it through a couple of DFFs clocked at 50MHz to convert it to that clock domain. 3) Use this output to disable the DFFs sampling the counter. 4) Take this disable signal, and run it back though a couple more DFFs, this time clocked at 77MHz, to generate a data valid signal in the 77MHz clock domain. Good luck. Let us know ultimately what ended up working for you, Marc Peter Alfke wrote: > If you do not want to convert to Gray code, you can also sample it > continuously and always compare the new sampled value with the previous one. > If they are identical, they are both good, if not, just continue until you > get a valid pair. > This method may have a problem when your (continuous?) count rate and sample > rate are so close together. > There are several ways to solve your problem, but you must realize that this > is a complex issue, not to be ignored. > > Peter Alfke > =========================== > >>Problem is that no matter how you re-sample it, you are sending multiple >>data bits (the counter output word) across clock domains, and you have the >>potential of getting incorrect data. I faced a similar problem, and I chose >>to convert the counter output to grey code, sample it in the new clock >>domain, and then convert back to binary. With grey encoding, only one bit >>changes at a time as you count up or down, so you cannot get incorrect data, >>even when there is a race condition when you re-sample. >> >>Barry Brown >> >>"prav" <praveenkn123@yahoo.com> wrote in message >>news:863df22b.0402172352.5886ed1c@posting.google.com... >> >>>hi all, >>> >>>I have a counter running at 50 Mhz . Now i have to sample that counter >>>at 77 Mhz. >>> >>>My question is can i sample the counter running at 50 mhz directly >>>with 77 mhz clock or should i synchronize the 50 mhz counter to 77 mhz >>>clock domain and then only sample it. >>> >>>what are the effects if i don't the sample the 50 Mhz counter and i >>>directly sample with 77 Mhz. >>> >>>rgds, >>>prav >> >> >Article: 66408
Check again. I'm downloading a version 3.1 that has todays date on it. I've downloaded previous versions, but never done much with them. It would be nice to add a little feature here or there. (like jumping to the source position from Insight to Visual Studio) Not sure if its worth it though with rumors of an improved IDE with Nios II. Ken "Jon Beniston" <jon@beniston.com> wrote in message news:e87b9ce8.0402181220.29d3bf08@posting.google.com... > Does anyone know where I can download the source to the NIOS GNU > toolchain? Altera's web site gives some instructions: > > http://www.altera.com/support/kdb/rd11272000_7307.html > > But when logging in to the FTP site, I can only see empty directories. > Any suggestions? > > Cheers, > JonBArticle: 66409
antti@case2000.com (Antti Lukats) writes: > Xilinx: connect config memory JTAG to FPGA Virtex 2 and Spartan 3 have ICAPs (Internal Configuration Access Points); the chip can reconfig itself with no external wiring. - a -- In 1845 the Potato Famine decimated Irish agriculture because of lack of genetic diversity. Over 150 years later, we still haven't learned this lesson, which is why the plague of Microsoft viruses will continue for as long as the software monoculture does.Article: 66410
jzakiya@mail.com (Jabari Zakiya) wrote in message news:<a6fa4973.0402181055.27856c3@posting.google.com>... > Corrections: > > The RTX 2000 had two 16-bit 256 element deep stacks (Return & Data), > a 2-4 cycle interrupt response time, and a bit-mutiply instruction which > could perform a complete general purpose multiply in 16-cycles. It was > rated a 8 MHz (but they could easily run at 10 MHz [which meant it took > a 20 MHz clock] at least at room temperatures). > > The RTX 2010 had all of the above, plus a one-cycle hardware 16-bit > multiply, a one-cycle 16-bit multiply/accumulate, and a one-cycle > 32-bit barrel shift. This was the version that Harris/Intersil based > the radhard version upon, which NASA and APL (Applied Physics Lab in > Columbia, MD) used for its space missions. They both still have a stash > left, the last that I heard. > > The RTX 2001 was a watered down version which was basically the 2000, > but with only 64 element deep stacks. It was intended (according to > Harris) to be a cheaper/faster alternative to the 2000, but like the > Celeron vs the Pentium, if you can get the real thing at basically the > same price, why use the neutered version? Plus, the reduction of stacks > from 256 elements to 64 element greatly reduced the ability to do > multi-tasking and stack switching. > > I used the RTX 2000/2010 extensively when I worked at NASA GSFC > Goddard Space Flight Center in Greenbelt, MD) from 1979-1994. I had two RTX boards. One was a rather expensive board six layer board with a Meg of SRAM and a shared memory interface to a PC ISA bus. It was from Silicon Composers. The other was one of the cheap European Indelko Forthkits, with RTX-cmForth, that I got from Dr. Ting. I had no experience with the 2010. I didn't remember that the 2001 had smaller stacks than the 2000 but I seemed to recall that the 2000 had a single cycle multiply and the 2001 had only the multiply step instruction. I no longer have the boards or the manuals and I don't think that Dr. Koopman's book goes into the details of what made the various models of RTX-20xx different. It was a long time ago, so I might have been confused about bit level details after all of these years. I spent a lot more years working with P21, I21 and F21 and have a much better memory of the bit level details there, it was also more recent. > I hope this helps set the history straight with regards to the differences > between the RTX versions. Too bad Harris didn't know how to market them. > > Jabari Zakiya Harris seemed to try first marketing it as Forth chip, then failing at that as a good realtime computer for use with C. I have often heard that it was too bad that they didn't know how to market it properly. Still I don't know if anyone really knows what they should-could-would have done to market it more successfully. They simply decided that they could easily market 80C286 that they could make on the same fab line. It also helps date those chips, Novix vs 8088, 8086 and RTX vs 80286. The realtime response, fast interrupt handling (relatively) and deterministic timing were where they won most easily, but they weren't 'backward compatible' with PC software like the Intel compatible chips so they were swimming upstream in their marketing efforts. Best WishesArticle: 66411
Hi, kkrishnan@wisc.edu (KaRtiK) wrote: > I was wondering as to are there any good resources online /and or some > tools > to learn about formal design verification of large complex designs > like for instance a processor. Formal Verification is usually divided in two subtopics: - structural equivalence checking - model/property checking Structural equivalence is easy done, but gives you no idea wheter you hit your specification. However it's very important to ensure your netlist is still in spec, if your rtl code was in spec. Especially after doing "handinsertions" or using selfmade tools on the netlist. Comercial tools for structural equivalence are - LEC from Verplex - Echeck from Prover - Formality from Synopsy - FormalPro from Mentor Model checking techniques are very difficult for complex processors but would give you a safety you hit your spec (or miss zhe spec *g*). There are also commercial tools available, AFAIK is none of the tools able do do complex designs nowadays. bye Thomas -- Please replace usenet_10 with thomas for PM.Article: 66412
jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0402181220.29d3bf08@posting.google.com>... > Does anyone know where I can download the source to the NIOS GNU > toolchain? Altera's web site gives some instructions: > > http://www.altera.com/support/kdb/rd11272000_7307.html > > But when logging in to the FTP site, I can only see empty directories. > Any suggestions? > Also, does anyone know of a document that details all of the instruction timings / latencies for NIOS? Cheers, JonBArticle: 66413
Hello,
I developed my own synchronous FIFO buffer using Virtex Block RAM.
However, when I try to simulate it on ModelSim XE 5.5e and 5.7c with ISE
WebPACK 4.2's Unisim library, I get the following error messages.
# ** Error:
../../../xilinx_webpack/verilog/src/unisims/RAMB4_S16_S16.v(453):
$recovery( posedge CLKA:690 ns, posedge
CLKB &&& clkb_enable:690 ns, 100 ps );
# Time: 690 ns Iteration: 2 Instance:
/FIFO_Testbench_Top/FIFO_Inst/BRAM_31_16
# ** Error:
../../../xilinx_webpack/verilog/src/unisims/RAMB4_S16_S16.v(453):
$recovery( posedge CLKA:690 ns, posedge
CLKB &&& clkb_enable:690 ns, 100 ps );
# Time: 690 ns Iteration: 2 Instance:
/FIFO_Testbench_Top/FIFO_Inst/BRAM_15_0
# ** Error:
../../../xilinx_webpack/verilog/src/unisims/RAMB4_S16_S16.v(453):
$recovery( posedge CLKA:720 ns, posedge
CLKB &&& clkb_enable:720 ns, 100 ps );
# Time: 720 ns Iteration: 2 Instance:
/FIFO_Testbench_Top/FIFO_Inst/BRAM_31_16
# ** Error:
../../../xilinx_webpack/verilog/src/unisims/RAMB4_S16_S16.v(453):
$recovery( posedge CLKA:720 ns, posedge
CLKB &&& clkb_enable:720 ns, 100 ps );
# Time: 720 ns Iteration: 2 Instance:
/FIFO_Testbench_Top/FIFO_Inst/BRAM_15_0
# ** Error:
../../../xilinx_webpack/verilog/src/unisims/RAMB4_S16_S16.v(453):
$recovery( posedge CLKA:750 ns, posedge
CLKB &&& clkb_enable:750 ns, 100 ps );
# Time: 750 ns Iteration: 2 Instance:
/FIFO_Testbench_Top/FIFO_Inst/BRAM_31_16
# ** Error:
../../../xilinx_webpack/verilog/src/unisims/RAMB4_S16_S16.v(453):
$recovery( posedge CLKA:750 ns, posedge
CLKB &&& clkb_enable:750 ns, 100 ps );
# Time: 750 ns Iteration: 2 Instance:
/FIFO_Testbench_Top/FIFO_Inst/BRAM_15_0
.
.
.
.
.
The above error messages were displayed when the FIFO contains
one entry, and the user logic tried to do simultaneous read/write of the
FIFO.
But if the FIFO contains two or more entries, simultaneous read/write of
the FIFO doesn't display the above error message, and the FIFO functions
correctly.
When the FIFO's RAM (Virtex Block RAM in dual-port mode.) is replaced
with Verilog's generic RAM, the FIFO functions correctly, so at this
point I suspect that something is wrong with Unisim's Virtex Block RAM.
Next thing I tried was to simulate synchronous version of a FIFO
buffer (fifoctlr_cc.v) in Xilinx Application Note 175 with the same
testbench code I used for testing my own FIFO.
Interestingly, I got error messages very similar to what I got with my
own FIFO.
# ** Error:
../../../xilinx_webpack/verilog/src/unisims/RAMB4_S8_S8.v(374):
$recovery( posedge CLKB:690100 ps,
posedge CLKA &&& clka_enable:690100 ps, 100 ps );
# Time: 660100 ps Iteration: 1 Instance:
/fifoctlr_cc_Testbench_Top/fifoctlr_cc_Inst/bram1
# ** Error:
../../../xilinx_webpack/verilog/src/unisims/RAMB4_S8_S8.v(374):
$recovery( posedge CLKB:720100 ps,
posedge CLKA &&& clka_enable:720100 ps, 100 ps );
# Time: 720100 ps Iteration: 1 Instance:
/fifoctlr_cc_Testbench_Top/fifoctlr_cc_Inst/bram1
# ** Error:
../../../xilinx_webpack/verilog/src/unisims/RAMB4_S8_S8.v(374):
$recovery( posedge CLKB:750100 ps,
posedge CLKA &&& clka_enable:750100 ps, 100 ps );
# Time: 750100 ps Iteration: 1 Instance:
/fifoctlr_cc_Testbench_Top/fifoctlr_cc_Inst/bram1
.
.
.
.
.
The application note doesn't say that fifoctlr_cc.v cannot
handle simultaneous read/write, so I am not sure why these error
messages get displayed.
Eventually I ran out of ideas, so I decided to try ISE 5.1's Unisim
library, and somehow this time the both FIFOs functioned correctly.
Am I doing something I am not supposed to do with Virtex's Block RAM, or
did Unisim's Virtex Block RAM contained a bug until the release of ISE
5.1 (Virtex was released in 1998)?
Kevin Brace (If someone wants to respond to what I wrote, I prefer if
you will do so within the newsgroup.)
Article: 66414Dear Sir or Madam, I want to design an SRAM controller for the asynchronous SRAM IDT71V256SA. Can somebody tell me if there is such a VHDL simulation model available? Thank you very much. Kind regards A.Vazquez G&D SystemDevelopmentArticle: 66415
How fast are the two clocks relative to each other? If one if much faster than the other use the 'fastest' one as the clock for the entire FIFO with the slower clock fed to an enable line so that when the slower clock edge comes along it will trigger it. If the two clks are almost the same, you could use a 'master clock' (make the whole thing sync to this clk signal) and use the other two 'FI-clock' and 'FO-clock' 's as enables. With this, you should be able to sync up your RAMs and still with Atmel or anything else, only use one 'master' clk. One finally suggestion: write your own FIFO don't use Atmel's (or any other vendor). It is a bit harder in the beginning, but if you must change chips, it is much easier to do. -Kip Mussatt "Fabio G." <9+3@supereva.it> wrote in message news:40216cd1.24157170@powernews.libero.it... > I have an Atmel AT94K40 FPGA and I need to synthesize (by writing VHDL) > a dual clock FIFO (a FIFO with different read and write clock). > The problem is that the Atmel macro-generator has the ability to > generate only single clock FIFO. > Is it possible that Atmel did not think to include the possibility of > creating dual clock FIFO's in an efficient way??? > Have I to design a FIFO by myself with "glue logic"?? In this way I > could not use the "FreeRAM" feature of the FPGA, and the resource use > would be critical. > Just to simulate my design, now I'm using a dual clock FIFO created with > the Altera macro generator, which uses a LPM_FIFO block. Do you think I > could try to synthesize this LPM_FIFO block in Atmel FPGA? > > > -- > Per rispondermi via email sostituisci il risultato > dell'operazione (in lettere) dall'indirizzo > -*- > To reply via email write the correct sum (in letters) > in the email addressArticle: 66416
Maybe http://www.microcore.org http://jpb.forth.free.fr/ will be of interest to you Roman "Davka" <mygarbagepail@hotmail.com> wrote in message news:T%XXb.70$pM3.121810@news.uswest.net... > Is there a community that is actively involved in discussing and/or > developing FPGA-based Forth chips, or more generally, stack > machines?Article: 66417
Hi, there: I don't understand why a big chunk Sun workstation runs ISE 6 much slower than a P3-1GHz!!! Is this the right behavior or my workstation is lousy? I remembered my Sun was bought 2 years ago, over 10K US$... Anybody use ISE on Unix? Thanks for your reply... KelvinArticle: 66418
My experience from ~4-5 years ago was that the PII ran the precursor to ISE about twice as fast as the unix machines I had access to. Of course, if someone else was doing anything intensive on the unix machine, it went further downhill. (Yes, if I ran other apps on the PC, things slowed down, too... but I could choose whether to run them or not.) I've seen similar results more recently with Spectrum and ModelSim (i.e., running significantly faster on what PC I had available versus the unix box I had available.) Jason "Kelvin @ SG" <kelvin8157@hotmail.com> wrote in message news:c12art$hg4$1@reader01.singnet.com.sg... > Hi, there: > > I don't understand why a big chunk Sun workstation runs ISE 6 much slower > than a P3-1GHz!!! > Is this the right behavior or my workstation is lousy? I remembered my Sun > was bought 2 years ago, > over 10K US$... > > Anybody use ISE on Unix? > > Thanks for your reply... > Kelvin > > >Article: 66419
Hi, Can anyone (Goran?) fill in some details of the Microblaze's pipeline for me? Do multi-cycle instructions always take multiple cycles? For example, if a load or shift is followed by an instruction that doesn't use the result of the load or shift, will the load or shift still cost two cycles? What is the branch penalty? Also, what does the 950 logic-cell figure include? Does it include the caches as well as all of the optional instructions / debug logic? Cheers, JonBArticle: 66420
Jeff Fox wrote: > > Harris seemed to try first marketing it as Forth chip, then failing > at that as a good realtime computer for use with C. I have often > heard that it was too bad that they didn't know how to market it > properly. Still I don't know if anyone really knows what they > should-could-would have done to market it more successfully. They > simply decided that they could easily market 80C286 that they > could make on the same fab line. It also helps date those chips, > Novix vs 8088, 8086 and RTX vs 80286. The realtime response, > fast interrupt handling (relatively) and deterministic timing > were where they won most easily, but they weren't 'backward > compatible' with PC software like the Intel compatible chips > so they were swimming upstream in their marketing efforts. I can't say for sure exactly what kind of marketing would have helped the RTX succeed. But I can tell you that any effort to pit it against the x86 line was misdirected. The x86 parts were not really embedded chips and I don't recall them being used as such very often. My memory may be failing me at this since this was long before there were chips aimed at the embedded market. But the Z80 and 8085 would have been the main competition for an embedded processor. The x86 line used too much board space and cost too much for most apps. It is likely that Harris did not understand what you do about the significant factors in embedded, realtime work. It has been more than once that a vendor needed to educate the engineering community about the features that make their products are a better way to go. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 66421
Update: version_0.5 of the not yet finished synthesizable vhdl ARM model is ready. Slowly but shurely we aproach a working version. First full release is now sheduled for March. Update: version_0.5 goto: http://www.l8arm.org/armiu.htmlArticle: 66422
"Kenneth Land" <kland1@neuralog1.com1> wrote in message news:<1038fig29qmvb27@news.supernews.com>... > Check again. I'm downloading a version 3.1 that has todays date on it. Bizzare. Perhaps they were in the process of updating it when I looked. I've now got it, but it fails to build GCC on either Linux or CygWin: ./genattr ../../src/gcc/config/nios/nios.md > tmp-attr.h './../src/gcc/config/nios/nios.md:211: unknown rtx code `define_split ../../src/gcc/config/nios/nios.md:211: following context is ` [(set (match_operand:SI 0 "general_operand" "")' Did it work for you? Cheers, JonBArticle: 66423
In comp.arch Martin Schoeberl <martin.schoeberl@chello.at> wrote: > "Sander Vesik" <sander@haldjas.folklore.ee> schrieb im Newsbeitrag > news:1077074083.882919@haldjas.folklore.ee... > > In comp.arch Martin Schoeberl <martin.schoeberl@chello.at> wrote: > > > > Is there a community that is actively involved in discussing > and/or > > > > developing FPGA-based Forth chips, or more generally, stack > > > > machines? > > > > > > > > > > Tha Java Virtual Machine is stack based. There are some projects > to > > > build a 'real' Java machine. You can find more information about a > > > solution in an FPGA (with VHDL source) at: > http://www.jopdesign.com/ > > > > > > It is sucessfully implemented in Altera ACEX 1K50, Cyclone (EP1C6) > and > > > Xilinx Spartan2. > > > > It would be intresting to see results for a version that cached the > > top of the stackand used a more realistic memory interface > > > Hallo Sander, > > In this design the stack is cached in a multi level hirarchy: > > TOS and TOS-1 are implemented as register A and B. The next level of > the stack is local memory that is connected as follows: data in is > connected to A and B, the output of the memory to the input of > register B. > Every arithmetic/logical operation is performed with A and B as source > and A as destination. All load operations (local variables, internal > register, external memory and periphery) result in the value loaded in > A. Therefore no write back pipeline stage is necessary. A is also the > source for store operations. Register B is never accessed directly. It > is read as implicit operand or for stack spill on push instructions > and written during stack spill and fill. > This configuration allows following operation in a single pipeline > stage: > ALU operation > write back result > fill from or spill to the stack memory > > The dataflow for a ALU operation is: > A op B => A > stack[sp] => B > sp-1 => sp > > for a 'load' operation: > data => A > A => B > B => stack[sp+1] > sp+1 => sp > > An instruction (except nop type) needs either read or write access to > the stack ram. Access to local variables, also residing in the stack, > need simultaneous read and write access. As an example, ld0 loads the > memory word pointed by vp on TOS: > stack[vp+0] => A > A => B, > B => stack[sp+1] > sp+1 => sp > > This configuration fits perfect to the block rams with one read and > one write port, that are common in FPGAs. A standard RISC CPU needs > three data ports (two read and one write) to implement the register > file in a ram. And usually one more pipeline stage for the ALU result > to avoid adding the memory access time to the ALU delay time. And for > single cycle execution you need a lot of muxes for data forwarding. yes, the block rams (with registers implemented in those) make FPGA-s have an interesting tradeoff - * you can have a large number of registers with no penalty * you are very limited in number of read/write ports, and adding more does not scale *AT ALL* > > As summary: In my opinion a stack architecture is a perfect choice for > the limited hardware resources in an FPGA. > > About the 'more realistic memory interface': > > I don't see the problem. The main memory interface is a separate block > and currently there are three different implementations for different > boards: a low cost version with slow 8 bit ram, a 32 bit interface for > fast async. ram and Ed Anuff added a 16 bit interface for the Xilinx > version on a BurchED board. Feel free to implement your interface of > choice (SDRAM,...). I see - just the benchmark numbers only used the simple 8-bit interface. > > Sorry for the long mail, but I could not resist to 'defend' my design > ;-) > > Martin > > -- Sander +++ Out of cheese error +++Article: 66424
Sander Vesik wrote: > > In comp.arch Martin Schoeberl <martin.schoeberl@chello.at> wrote: > > An instruction (except nop type) needs either read or write access to > > the stack ram. Access to local variables, also residing in the stack, > > need simultaneous read and write access. As an example, ld0 loads the > > memory word pointed by vp on TOS: > > stack[vp+0] => A > > A => B, > > B => stack[sp+1] > > sp+1 => sp > > > > This configuration fits perfect to the block rams with one read and > > one write port, that are common in FPGAs. A standard RISC CPU needs > > three data ports (two read and one write) to implement the register > > file in a ram. And usually one more pipeline stage for the ALU result > > to avoid adding the memory access time to the ALU delay time. And for > > single cycle execution you need a lot of muxes for data forwarding. > > yes, the block rams (with registers implemented in those) make FPGA-s > have an interesting tradeoff - > * you can have a large number of registers with no penalty > * you are very limited in number of read/write ports, and > adding more does not scale *AT ALL* The older Xilinx parts have small LUT based rams that have true 3 port memory. But how they implemented it shows that you can always make a 3 port memory from a pair of two port memories. They tied the two write ports together so that the two RAMs always were written with the same data. But the read ports were kept separate allowing any two words to be read at the same time. > > As summary: In my opinion a stack architecture is a perfect choice for > > the limited hardware resources in an FPGA. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
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