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
> This is along the lines of what I expected. Dual port ram is > definitely a possibility, do you have any suggestions as to a part? > Like I said, I'd be looking for a minimum of 64KB. On one side of the > DP RAM would be the Spartan-3E, and on the other would be a NetBurner > module (a pretty average microcontroller). Alex, what sort of clock speed is the uC running at? One solution is to pipeline the uC access to the ram through the FPGA then alternate access between the uC interface and the FPGA process that's doing the clever bits. If the uC clock is slow this becomes much easier to implement. NialArticle: 104751
On Wed, 05 Jul 2006 10:41:00 -0500, hmurray@suespammers.org (Hal Murray) wrote: >>In normal (my normal, anyway) usage of the term 'metastable', what's >>meant is an asychronous circuit with feedback, in which more than one >>input changes 'simultaneously', leading to oscillation because of a >>hazard. In practical circuits, the oscillation is damped and decays. > >It doesn't take two inputs. You can get metastability with a simple >runt pulse into a R/S FF. These are analog circuits, so you can always find a way to set a gate input such that an output is neither '0' nor '1'. Is that metastability? This is just semantics, but I would say not; it's just another (uninteresting) way to get an invalid output. Philip Freidin's article (the link posted by Symon) appears to talk exclusively about the multi-input synchronisation version of metastability, which is what I understand the word to mean. EvanArticle: 104752
"mk" <kal*@dspia.*comdelete> wrote in message news:2iqma2the96cnlaujjgi40c5fv4tngc05o@4ax.com... > On 5 Jul 2006 00:07:24 -0700, saumyajit_tech@yahoo.co.in wrote: > >>2) My point number 2 is reagrding putting some logic( SRL16, FFs..) in >>the reset ckt. I am afraid, it vilaotes the basic rule of >>controllability of DFT. I should be able to control the state of all >>the FFs from a single reset pin out side the chip. is not it true ? > > You can always insert control points after your reset logic so that > when you enable test the flops become externally controllable again. > It's easy to do this with current scan insertion tools. I thought we were talking about FPGAs ... the DFT logic for the FPGA is already in the FPGA and is completely independant of the design that you put in the FPGA. You don't use scan insertion tools for FPGAs .. that's ASIC land. MikeArticle: 104753
Let's go back to the word origin and the definition: meta (from the Greek) means "between", stable (from Latin) means, well, stable... In electronics it is used to describe a circuit with positive feedback that is unconditionally stable at either of two levels (High and Low) but can also be "metastable" in the balanced condition. In the stable conditions, a small disturbance (epsilon) will cause the state to revert to the previous stable state, but in the metastable state any disturbance will cause the circuit to go to the nearest stable state. That's what is also true in the analogy of the pen standing on its tip. Try it! Peter Alfke, Xilinx ================== Evan Lavelle wrote: > On Wed, 05 Jul 2006 10:41:00 -0500, hmurray@suespammers.org (Hal > Murray) wrote: > > >>In normal (my normal, anyway) usage of the term 'metastable', what's > >>meant is an asychronous circuit with feedback, in which more than one > >>input changes 'simultaneously', leading to oscillation because of a > >>hazard. In practical circuits, the oscillation is damped and decays. > > > >It doesn't take two inputs. You can get metastability with a simple > >runt pulse into a R/S FF. > > These are analog circuits, so you can always find a way to set a gate > input such that an output is neither '0' nor '1'. Is that > metastability? This is just semantics, but I would say not; it's just > another (uninteresting) way to get an invalid output. > Philip Freidin's article (the link posted by Symon) appears to talk > exclusively about the multi-input synchronisation version of > metastability, which is what I understand the word to mean. > > EvanArticle: 104754
On 5 Jul 2006 13:56:50 +0200, "Symon" <symon_brewer@hotmail.com> wrote: >Hi Evan, >Not all metastablility manifests itself as an oscillation. e.g. CMOS FFs. In Sure, I agree; I thought I'd covered that with my comment on the switching energy and the damping. Having said that, I like to think of metastability in terms of hazards in K-maps. If you do the wrong thing to the inputs, and the K-map says that the output oscillates (or you have one switching input and a hazard), then you've got metastability. What actually happens in a practical circuit will depend on how it's constructed. EvanArticle: 104755
http://www.google.com/search?hl=pt-BR&q=xilinx+using+block+ram It depends on the size of your fpga. Alex escreveu: > My application needs a somewhat large memory array, for constant (every > clock cycle) sequential read/write access -- the size in question is > exactly 64KB (524288 bits). > > Is a memory block of this size reasonable / possible to do in just > VHDL? My FPGA in question is a Spartan-3E, and we have not yet decided > upon the exact package yet. > > If this task is not feasible in VHDL alone, what external RAM device > might be recommended? Having the VHDL for access to such an external > RAM available for reference would be a big boon here. > > A side note on how this memory block will be used. One "task" will be > iterating over the block repeatedly, with data trickling in replacing > old values -- so each incoming byte stored in the RAM will be accessed > many times before it is overwritten. > > Any tips or links to materials regarding this would be greatly > appreciated. > > Thank you. > > Alex McHaleArticle: 104756
Peter Alfke wrote: > Let's go back to the word origin and the definition: > meta (from the Greek) means "between", stable (from Latin) means, well, > stable... > > In electronics it is used to describe a circuit with positive feedback > that is unconditionally stable at either of two levels (High and Low) > but can also be "metastable" in the balanced condition. > In the stable conditions, a small disturbance (epsilon) will cause the > state to revert to the previous stable state, but in the metastable > state any disturbance will cause the circuit to go to the nearest > stable state. > That's what is also true in the analogy of the pen standing on its tip. > Try it! But you have not responded as to why the FF can not oscillate. The FF is more than just a penl standing on end or a ball on a hill. A FF is a dynamic system with feedback and delays. My schooling taught me that with the right combination of delay and gain (or the wrong combination) it can oscillate. What makes these FFs different? The pen analogy is not a lot different from the pendulum. Yet a pendulum can be chaotic! I think the pen is only good as a first order approximation. For this sort of issue, the analogy requires further scrutiny.Article: 104757
Hi groups, I got a spartan3E starter kit and have experienced trouble with usb jtag interface. While using Impact, usb cable can connect with my laptop, but not on my desktop pc. However pc usb port/controler seems ok : there are other devices connected : wireless lan, external HD and CD/DVD recorder checked numerous cables... any clues, regards Connecting to cable (Usb Port - USB21). Checking cable driver. Driver xusbdfwu.sys version: 1018 (1018). Driver windrvr6.sys version = 7.0.0.0. Max current requested during enumeration is 280 mA. Loopback test failed. Sent character = 10, Received character = 32. Cable connection failed.Article: 104758
Hi, Which is better --- to have plb master with xilinx ipif in it or without it? I want to avoid ipif but wanted to know if it will affect performance? Thanks, NiteshArticle: 104759
radarman wrote: > > If you want to do it all internally, the only part big enough is the > XC3S1600E. However, you could simply plop on an external SRAM, have > enough RAM left over for growth, and get by with a MUCH smaller FPGA. > Even better would be an appropriately sized external dual-port RAM. > This would allow you to just implement your control logic and data > interface in the FPGA, which (depending on your application) could be a > much smaller device. > > FPGA's make for some very expensive RAM. If you need RAM in bulk, it's > generally better to just add RAM unless you have some other constraint > that forbids it. > I think you'll find that dual port RAM makes the FPGA look cheap. Dual port RAM devices are not generally commodity items, and the ones that are out there tend to dissappear into no longer available land pretty quickly. Since you already have the FPGA in the system, use the FPGA as an interface to a standard single ported RAM and time-multiplex the access. You'll need 2x the RAM bandwidth, so if you are limited in the clock period, double the width of the memory to make up for the slower time-multiplexed access. Use a few of the dual ported BRAMs in the FPGA to buffer data into and out of the SRAM and for clock domain crossings.Article: 104760
PeterSmith1954@googlemail.com wrote: > > The last time I used *9 / *18 / *36 mode block rams, I instantiated > them as such and they exposed themselves as those *8 + the parity bit. > Look for the instantiation template and you'll see what I mean. > > Just assign your ninth bit (for each block ram) to the parity bit. > > Cheers > > PeteS > The primitives have the bits separated off as parity bits, but other than the addressing considerations if you have different depths on the dual ports, they are no different than the data bits. It may be easier to deal with if you make a wrapper for the Xilinx primitives that bring in/out an 18 bit bus.Article: 104761
Robin Bruce wrote: > Thanks Ben, > > it's always good to know that I'm not imagining the problem. I'm using > ISE 8.1, service pack 3. I should probably point out at this point that > the purpose of this little project is as much about design methodology > as it is about having a functioning design. I'm aware that there's > about a million ways I could do this, but in order to have a portable > core that can be easily floorplanned, I want to have all my design > files as standard VHDL with no specific instantiations of FPGA > resources, nor any NGC files from CoreGen. > > > You'll generally have far better results instantiating the DSP48's with everything set up the way you want it. I realize you want RTL-only for portability. How about instead putting a wrapper around the DSP48 instantiation so that it appears as a generic pipelined multiplier. If you port to another device, just replace the wrapper with one appropriate for that device. If you want, put your wrapper file(s) in a separate subdirectory so that you can quickly identify which ones need to be replaced if you make a technology change. Making up new wrappers for a new device should not require much effort or time.Article: 104762
Robin Bruce wrote: > Martin, > > >>Have you had a look in FPGA editor to see what's going on? > > > This is where I myself look dim: I did open up the NCD file in the FPGA > Editor. I didn't really know what to do to tell if the right > registering was occurring. All I could see was that all 4 DSP48s were > instantiated together in a little row. I've never used FPGA editor > before. I'm more familiar with PlanAhead for looking at that sort of > thing, but I don't have that on my laptop, my current working platform. > > >>Is it actually this bit of code that limits the timing? > > > Well, all I can say is that I don't think so. It could very well be > though, but I've tried writing the VHDL in very different ways, guided > by things I've found in one or two guides to instantiating the DSP48s > in VHDL. Every way I write the VHDL, the same performance is obtained. > The thing is that I can see that the synthesis tool is making some kind > of effort to pipeline the thing. > > This is the critical path that comes out of the synthesis report if > this means anything to anyone: > > Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35 > Gate Net > Cell:in->out fanout Delay Delay Logical Name (Net Name) > ---------------------------------------- ------------ > DSP48:CLK->PCOUT47 1 4.399 0.000 mult_inst/Mmult__n00001 > (mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47) > DSP48:PCIN47->PCOUT47 1 2.363 0.000 > mult_inst/Mmult__n00002 > (mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47) > DSP48:PCIN47->PCOUT47 1 2.363 0.000 > mult_inst/Mmult__n00003 > (mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47) > DSP48:PCIN47->P35 1 2.270 0.534 mult_inst/Mmult__n00004 > (mult_inst/Mmult__n0000_s_69) > FD:D 0.391 mult_inst/Mmult__n0000_0 > ---------------------------------------- > Total 12.320ns (11.786ns logic, 0.534ns route) > (95.7% logic, 4.3% route) > > Cheers, > > Robin > Your design is not inferring the P register, so the adders are combinatorial. The adders get connected in a daisy chain. You may have to recode your RTL to reflect that, as the synthesizer is not really smart enough to push around the registers to the degree necessary to deal with differing latencies among the adder inputs.Article: 104763
Evan Lavelle wrote: > On 5 Jul 2006 13:56:50 +0200, "Symon" <symon_brewer@hotmail.com> > wrote: > > >>Hi Evan, >>Not all metastablility manifests itself as an oscillation. e.g. CMOS FFs. In > > > Sure, I agree; I thought I'd covered that with my comment on the > switching energy and the damping. > > Having said that, I like to think of metastability in terms of hazards > in K-maps. If you do the wrong thing to the inputs, and the K-map says > that the output oscillates (or you have one switching input and a > hazard), then you've got metastability. What actually happens in a > practical circuit will depend on how it's constructed. > > Evan That's different than metastability. You are talking about dynamic hazards (race conditions). Given a sequence of inputs and a circuit with a dynamic hazard, the circuit will respond exactly the same way every time the same input (levels and timing) is applied. Although the operation may not be what the designer intended due to the dynamic hazards, it is still a deterministic system. Metastability is a very specific condition where the outcome is not deterministic. It occurs in a system with positive feedback when the input changes occur in such a way (with a very specific timing) that the circuit ends up balancing in a state that is neither '1' nor '0'.Article: 104764
Nitesh wrote: > Hi, > Which is better --- to have plb master with xilinx ipif in it or > without it? > I want to avoid ipif but wanted to know if it will affect performance? > Thanks, > Nitesh > Your solution with the IPIF will almost be better. I had to do a PLB master implementation and could not get the IPIF to work correctly. I spent a day reading through the spec on PLB and wrote my own. -ELiArticle: 104765
Thanks to everyone who has replied. Can anyone point me to a good resource on learning to interface the FPGA with a RAM chip? I'm using VHDL for everything in the FPGA. The more example VHDL I can see, the better. This is a project that landed in my lap that I'm having to learn a lot for as I go. The more resources I have to learn how to use this FPGA and VHDL, the better. Thank you. Alex McHaleArticle: 104766
ok, thanks for your answers everyone. The "fun" i was talking about is the usual hobby-retro stuff. I would also like to play with microblaze/nios2 a bit. Anyway, i still have three questions for you: 1. What is the third party thing they sell for $49? is it just a JTAG cable? 2. How does the board work with NIOS II (from what i understand, "free" pre compiled SoC exists for some development boards. does it include this one?). Or Xilinx EDK for that matter? 3. What does the nanoboard cost? What do they charge for shiping to EU? (Altium sales wouldnt answer those!). You could mail me directly for the last one I still think the boards are very cheap, Altera NIOS II board with the same FPGA costs $500 (ok, it has more stuff on the board, but who needs them?). Even the very cheep T-rex board is more expensive and has a smaller FPGA. Also, their software might turn out to be good [it might even be cheaper than our current development environments]. other than that, i wouldn't mind buying Antti's brain for one dollar :) regards, -BurnsArticle: 104767
Ray Andraka wrote: > > > That's different than metastability. You are talking about dynamic > hazards (race conditions). Given a sequence of inputs and a circuit with > a dynamic hazard, the circuit will respond exactly the same way every > time the same input (levels and timing) is applied. Although the > operation may not be what the designer intended due to the dynamic > hazards, it is still a deterministic system. Metastability is a very > specific condition where the outcome is not deterministic. It occurs in > a system with positive feedback when the input changes occur in such a > way (with a very specific timing) that the circuit ends up balancing in > a state that is neither '1' nor '0'. Let me continue the story: And that balanced state may even appear like a legitimate 1 or 0 on the circuit output, but the internal falling back into the stable 1 or 0 may (or may not) create an output transition that occurs at a non-deterministic time after the clock edge that started the operation. It is this unknown (and unknowable) delay that can create havoc in an otherwise synchronous system. Peter Alfke, XilinxArticle: 104768
MikeJ wrote: > I have added some notes to www.fpgaarcade.com describing how to modify the > Spartan kit board to have 12 bit RGB output on the VGA port. > > Also included is some test pattern code / bitfile to produce some output. > > /MikeJ Here's an idea for 8-bit color, and some examples of how it can look if you dither. http://jpb.forth.free.fr/Anglais/pages_techniques/vga.html Regards, KeithArticle: 104769
> > Your solution with the IPIF will almost be better. I had to do a PLB > master implementation and could not get the IPIF to work correctly. I > spent a day reading through the spec on PLB and wrote my own. > > -ELi I had about the same experience with OPB master. GuruArticle: 104770
Hi folks, I have a problem and I need a clean solution: I created an OPB peipheral which includes AsyncFIFO (created with FIFO generator). I have included the edn (tried also with ngc) in bbd file and a VHDL wrapper (original, created by CoreGen). During build I get the following error: ERROR:NgdBuild:604 - logical block 'imam_0/imam_0/FIFO' with type 'async_fifo' could not be resolved. A pin name misspelling can cause this, a missing edif or ngc file, or the misspelling of a type name. Symbol 'async_fifo' is not supported in target 'virtex4'. I did managed to overcome the problem somehow several times by changing bbd and netlist filenames, but the problem comes to the surface every time I clean all the EDK project files. GuruArticle: 104771
rickman wrote: > Peter Alfke wrote: > >>Let's go back to the word origin and the definition: >>meta (from the Greek) means "between", stable (from Latin) means, well, >>stable... >> >>In electronics it is used to describe a circuit with positive feedback >>that is unconditionally stable at either of two levels (High and Low) >>but can also be "metastable" in the balanced condition. >>In the stable conditions, a small disturbance (epsilon) will cause the >>state to revert to the previous stable state, but in the metastable >>state any disturbance will cause the circuit to go to the nearest >>stable state. >>That's what is also true in the analogy of the pen standing on its tip. >>Try it! > > > But you have not responded as to why the FF can not oscillate. The FF > is more than just a penl standing on end or a ball on a hill. A FF is > a dynamic system with feedback and delays. My schooling taught me that > with the right combination of delay and gain (or the wrong combination) > it can oscillate. What makes these FFs different? > > The pen analogy is not a lot different from the pendulum. Yet a > pendulum can be chaotic! I think the pen is only good as a first order > approximation. For this sort of issue, the analogy requires further > scrutiny. Put this into a Spice pgm, and try it. In fact, (good) spice should be able to show the settling-time-extension effects of metastability quite well. It would need carefull sweep of the drive voltage, at the instant the clock does the hand-over. The FF I am used to, is Analog transmission gates, around single CMOS INV/OR gates - two forming the regenerative latch. These simple 'unbuffered' CMOS structures have finite analog gain, even at their peak, in the linear region. (unlike TTL ones ) To build an oscillator, you must hold them in the linear region (DC), and provide phase shift at some other frequency, where the loop gain is still over unity. Yes, there are parasitics all around, but the FF lacks the linear-bias mechanism, so it cannot sustain oscillation. I am sure some would look pretty knarly, as they settled, and may not be monotonic, but these times will be very short. During this settling time, they will also be at their most sensitive to crosstalk effects. -jgArticle: 104772
The async_fifo.edn is generated on the fly through some HDL pragma calls that XST understands. To integrate this into EDK flow, add OPTION RUN_NGCBUILD=TRUE into the MPD of your pcore. This allows platgen to integrate sub-netlist files into the generated NGC file produced by XST. Guru wrote: > Hi folks, > > I have a problem and I need a clean solution: > I created an OPB peipheral which includes AsyncFIFO (created with FIFO > generator). I have included the edn (tried also with ngc) in bbd file > and a VHDL wrapper (original, created by CoreGen). During build I get > the following error: > ERROR:NgdBuild:604 - logical block 'imam_0/imam_0/FIFO' with type > 'async_fifo' could not be resolved. A pin name misspelling can cause > this, a > missing edif or ngc file, or the misspelling of a type name. Symbol > 'async_fifo' is not supported in target 'virtex4'. > I did managed to overcome the problem somehow several times by changing > bbd and netlist filenames, but the problem comes to the surface every > time I clean all the EDK project files. > > Guru >Article: 104773
>Gary,
>
>h doesn't have a source in your code. You need to add something like
this:
>h <= slv_reg0;
>Or just use slv_reg0 instead of h as input to your inverter and in the
read
>process.
>
>/Mikhail
>hey,
In user_ip.vhd file i used the following instantation in user logic
implementation
h<=slv_reg0;
k<=slv_reg1;
again synthesis is going on well but the same errors what i posted in my
first message are coming again.
And in the second method i disabled h & k signals directly i assigned
portmap(slv_reg0,slv_reg1) in following way
------------
component inverter
port( s : in std_logic_vector(0 to 31);
t : out std_logic_vector(0 to 31));
end component;
---attribute box_type : string;
--attribute box_type of inverter : component is "black_box";
begin
we: inverter
port map(slv_reg0,slv_reg1);
----------------------------
while synthesis following errors are generated....
ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal <slv_reg1<9>>
Sources are:
Output signal of OBUF instance <we/t_9_OBUF>
Output signal of FDRE instance <slv_reg1_9>
ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal
<slv_reg1<13>>
Sources are:
Output signal of OBUF instance <we/t_13_OBUF>
Output signal of FDRE instance <slv_reg1_13>
ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal
<slv_reg1<21>>
Sources are:
Output signal of OBUF instance <we/t_21_OBUF>
Output signal of FDRE instance <slv_reg1_21>
ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal
<slv_reg1<27>>
Sources are:
Output signal of OBUF instance <we/t_27_OBUF>
Output signal of FDRE instance <slv_reg1_27>
----------------for all 0 to 31----------------------------
/gary
Article: 104774You may have already done this, but I thought to point it out anyway: Make sure that the core netlist (edn, etcc) is in the directory like this pcores/your_core_v_1_00a/netlist And the bbd file should have lines like below: FILES your_netlist_names HTH, Jim http://home.comcast.net/~jimwu88/tools/ Guru wrote: > Hi folks, > > I have a problem and I need a clean solution: > I created an OPB peipheral which includes AsyncFIFO (created with FIFO > generator). I have included the edn (tried also with ngc) in bbd file > and a VHDL wrapper (original, created by CoreGen). During build I get > the following error: > ERROR:NgdBuild:604 - logical block 'imam_0/imam_0/FIFO' with type > 'async_fifo' could not be resolved. A pin name misspelling can cause > this, a > missing edif or ngc file, or the misspelling of a type name. Symbol > 'async_fifo' is not supported in target 'virtex4'. > I did managed to overcome the problem somehow several times by changing > bbd and netlist filenames, but the problem comes to the surface every > time I clean all the EDK project files. > > Guru
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