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
"dlopez" <d@n_o_s_p_a_m.designgame.ca> writes: > If I want to save area, is it better to use a CRC that works byte > per byte or bit per bit? Per bit as it is simply a shift register with xor gates at the polynomial positions. Here is a sample program to symbolically convert a serial form to a parallel form: http://tinyurl.com/ygvenaz Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 145251
Dear Sir/Madam, The code that I posted is actually a task in a large Verilog module. This large module was simulated separately with ModelSim 6.5c and open-source Icarus Verilog 0.9.1. In both cases, the simulation results were as I had expected them to be. It was only after these two simulations were run, code modified and re-run a number of times that I tried this synthesis with Xilinx ISE 11.1. Unfortunately, when I tried the whole design, Xilinx gave a 'out of memory' error at the end, forcing me to divide the module into sub-modules. Indeed, the 'outtail' is a typo, but I had already corrected and tried synthesis before the original post. I fully agree with what you say, but for some reason that I do not understand, Xilinx's XST thinks this is an empty module. Thank you. On Feb 3, 11:09 am, Muzaffer Kal <k...@dspia.com> wrote: > On Mon, 1 Feb 2010 21:28:38 -0800 (PST), Daku <dakup...@gmail.com> > wrote: > > ... > > Before you try to synthesize anything, you should first simulat what > you wrote (or what a tool generated for you?) Your module has no > outputs (but a port named outtail, typo?) so all logic (including > your clock signal) will be removed. If you put this module in a > testbench and try to get to what ever it's calculating you will figure > this out very quickly. > > Also the coding style of the module is quite error-prone. Invest some > time in learning how to write synthesizable rtl for the time you'll > actually do synthesis so that you won't have to revise all your code > after you think you're done typing. > -- > Muzaffer Kal > > DSPIA INC. > ASIC/FPGA Design Services > > http://www.dspia.comArticle: 145252
On Feb 3, 11:02=A0am, Daku <dakup...@gmail.com> wrote: > Dear Sir/Madam, > The code that I posted is actually a task in a large > Verilog module. This large module was simulated > separately with ModelSim 6.5c and open-source > Icarus Verilog 0.9.1. In both cases, the simulation > results were as I had expected them to be. > > It was only after these two simulations were run, code > modified and re-run a number of times that I tried this > synthesis with Xilinx ISE 11.1. Unfortunately, when I > tried the whole design, Xilinx gave a 'out of memory' > error at the end, forcing me to divide the module into sub-modules. > > Indeed, the 'outtail' is a typo, but I had already corrected > and tried synthesis before the original post. I fully agree > with what you say, but for some reason that I do not > understand, Xilinx's XST thinks this is an empty module. > > Thank you. > > On Feb 3, 11:09 am, Muzaffer Kal <k...@dspia.com> wrote: > > > On Mon, 1 Feb 2010 21:28:38 -0800 (PST), Daku <dakup...@gmail.com> > > wrote: > > > ... > > > Before you try to synthesize anything, you should first simulat what > > you wrote (or what a tool generated for you?) Your module has no > > outputs (but a port named outtail, typo?) so all =A0logic (including > > your clock signal) will be removed. If you put this module in a > > testbench and try to get to what ever it's calculating you will figure > > this out very quickly. > > > Also the coding style of the module is quite error-prone. Invest some > > time in learning how to write synthesizable rtl for the time you'll > > actually do synthesis so =A0that you won't have to revise all your code > > after you think you're done typing. > > -- > > Muzaffer Kal > > > DSPIA INC. > > ASIC/FPGA Design Services > > >http://www.dspia.com > > Maybe if you post the corrected code as rejected by Xilinx someone can comment on it. I don't see any assignment made to the "output" outtail in the code you originally posted. regards, GaborArticle: 145253
On Jan 29, 5:47=A0pm, EE EE <eengr....@gmail.com> wrote: > I want to synthesize a completely empty design, no clocks no combo and > no sequential logic for a xilinx FPGA using ISE. Would the following satisfy your requirements? 1. open a new design in fpga_editor (chose your part, etc.) and save it to empty.ncd 2. bitgen empty.ncd ...you then get an "empty" bitstream, empty.bit. saar.Article: 145254
On Feb 1, 9:28=A0pm, Daku <dakup...@gmail.com> wrote: > Could some Xilinx guru please help ? I have the following module > synthesized on Xilinix ISE 11.1. I am getting a message at the end of > synthesis that no clock exists for design - could some please kindly > explain what it means ? > > `timescale 1ns / 1ps > /////////////////////////////////////////////////////////////////////////= //=AD/////// > // Company: > // Engineer: > // > // Create Date: =A0 =A000:08:55 02/02/2010 > // Design Name: > // Module Name: =A0 =A0GetTail > // Project Name: > // Target Devices: > // Tool versions: > // Description: > // > // Dependencies: > // > // Revision: > // Revision 0.01 - File Created > // Additional Comments: > // > /////////////////////////////////////////////////////////////////////////= //=AD/////// > module GetTail( > =A0 =A0 input [0:0] clock, > =A0 =A0 input [0:511] inarr, > =A0 =A0 input [0:31] inpriority, > =A0 =A0 input [0:31] intail, > =A0 =A0 input [0:31] innum, > =A0 =A0 input [0:31] toppriority, > =A0 =A0 input [0:31] outtail > =A0 =A0 ); > > parameter MAX =3D 512; > parameter DATA_WIDTH =3D 32; > > reg [0 : 31] localtail; > > initial > =A0begin > =A0 localtail =3D intail; > =A0end > > always @ (posedge clock) > =A0 if(inpriority =3D=3D 0) > =A0 =A0begin > =A0 =A0 =A0 if(innum > 0 =A0&& > =A0 =A0 =A0 =A0 =A0inarr[localtail] =3D=3D 0 && > =A0 =A0 =A0 =A0 =A0inarr[localtail + 1] =3D=3D 1) > =A0 =A0 =A0 =A0 begin > =A0 =A0 =A0 =A0 =A0 =A0localtail =3D localtail + 1; > =A0 =A0 =A0 =A0 end > > =A0 =A0 =A0 else if(innum > 0 && > =A0 =A0 =A0 =A0 =A0 =A0 =A0localtail =3D=3D MAX - 1 && > =A0 =A0 =A0 =A0 =A0 =A0 =A0inarr[localtail] =3D=3D 0) > =A0 =A0 =A0 =A0 =A0begin > =A0 =A0 =A0 =A0 =A0 =A0localtail =3D 0; > =A0 =A0 =A0 =A0 =A0end > =A0 end > =A0 else if(inpriority > 0) > =A0 =A0begin > =A0 =A0 localtail =3D toppriority; > =A0 =A0end > > endmodule > > Any hints, suggestions would be of immense help - thanks in advance. In your code you wrote: > input [0:0] clock, > .... > always @ (posedge clock) These are not the same thing. The first usage is a vector with single bit number of 0 which is expanded as "clock[0]". Ed McGettigan -- Xilinx Inc.Article: 145255
I know Antti has a lot of experience with Actel, so I expect to hear from him, but I am sure there are others out there with experience of Actel tools. A customer of mine has told me that he used Actel for a project some 4 or 5 years ago and had a problem with the tools that Actel could not give a fix for. I don't recall how he worked around it and I am sure that particular issue has been fixed, but I now have the impression that the Actel tools are not as good as tools from the other three. I seem to recall some significant issues being discussed here. Can anyone confirm or dispute it the relative quality of Actel tools? Am I mistaken about them? RickArticle: 145256
On Feb 3, 4:17=A0pm, Make Money Online <incomeforlife...@gmail.com> wrote: > Discover How to Cure Panic Attacks Today: > > http://www.how-to-cure-panic-attacks.eoltt.com/ > > Is Any Of This Experience Familiar To You? > > =A0 =A0 * Maybe you found yourself in the hospital's ER because you > thought you were having a heart attack only to be told later it was > anxiety? > =A0 =A0 * Do you ever fear you might stop breathing because your chest > feels tight and your breathing erratic? > =A0 =A0 * When you drive do you fear the idea of getting stuck in traffic= , > on a bridge or at red lights? > ..... > > Do You Feel Any Of The Following Bodily Sensations? > > =A0 =A0 * Dizzy spells leading to panic > =A0 =A0 * Tightness in throat and chest- shortness of breath > =A0 =A0 * Racing heart with tingle sensations > =A0 =A0 * Hot flushes followed by waves of anxiety > ..... > > http://www.how-to-cure-panic-attacks.eoltt.com/ Is there some irony to this being posted here? Surely FPGA designers have no problems that might cause panic attacks! RickArticle: 145257
On Feb 3, 10:13=A0am, Petter Gustad <newsmailco...@gustad.com> wrote: > "dlopez" <d@n_o_s_p_a_m.designgame.ca> writes: > > If I want to save area, is it better to use a CRC that works byte > > per byte or bit per bit? > > Per bit as it is simply a shift register with xor gates at the > polynomial positions. > > Here is a sample program to symbolically convert a serial form to a > parallel form: > > http://tinyurl.com/ygvenaz To do a serial CRC calculation requires a state machine to control it. A parallel CRC has to perform multiple xors for each bit using extra logic compared to the bit serial version, the difference depending on the size of the CRC. The question is which uses more logic, a byte parallel CRC generator or the control logic for the state machine. Depending on the CRC chosen, I bet it is close to a wash, but the only way to know for sure is to build both and see.Article: 145258
Hi guys.. I'm getting ready to start working on my first board layout with a BGA package (FG456). First will be a prototype for sure. I was just wondering a few things... Probably the critical part of my design will be interface to a few asynchronous SRAMs. In a relatively low speed design (buses at 10-25MHz) do I need to worry about things like termination and trace length on the RAM buses? Should I dedicate address/data pins to each chip in a shared memory space, or is it better to daisy chain them on a bus? (It seems to me that routing will be a little easier if each chip gets its own lines..) If I won't be using the innermost IO pins, can I get away with a 4- layer design, two signal layers and power/ground? Looking at a Xilinx app note with a suggested escape route for this package, they have three signal layers with 5 mil width traces, the third of which I believe I can do without... And lastly, I guess that I will be needing 1.8 and 2.5V supplies, as well as 3.3V for all of my I/O supplies.. should these all be routed in the dedicated power layer? If the layer is mostly covered a plane, which voltage is supposed to be the plane? 3.3V? And lastly, when connecting I/Os, is there any sensible approach? My tendency is to want to choose the I/Os so that everything lines up nicely, but I find it to be a hassle in this case, that in Eagle we have to connect nets in the schematic first and can't back-annotate from the board. Anything else I should be worrying about? Cheers, SteveArticle: 145259
In article <1e71b867-02c0-4702-973b-355411c39446@t21g2000vbo.googlegroups.com>, rickman <gnuarm@gmail.com> writes: >To do a serial CRC calculation requires a state machine to control >it. A parallel CRC has to perform multiple xors for each bit using >extra logic compared to the bit serial version, the difference >depending on the size of the CRC. The question is which uses more >logic, a byte parallel CRC generator or the control logic for the >state machine. Depending on the CRC chosen, I bet it is close to a >wash, but the only way to know for sure is to build both and see. The bit serial CRC has a simple structure. It can easily run at a high clock rate. The parallel CRC turns into an ugly cloud of XORs. The details depend upon the polynomial and how many bits you are processing in parallel. Expect it to turn into a good test case for the placer and router. If the OP doesn't have enough clocks to process things in bit serial, it might work out better to do 2 bits in parallel on each of 4 clocks. I think that needs 4 inputs worst case so it fits in one layer of LUT. (I'm rusty on this, but years ago I spent a lot of time in this area. I think I've made all possible screwups while writing software to check things. There are a lot of wrong possibilities when you consider big endian vs little endian, shifting right or left or ...) -- These are my opinions, not necessarily my employer's. I hate spam.Article: 145260
On Feb 4, 12:22=A0am, TSMGrizzly <sbatt...@yahoo.co.jp> wrote: > Hi guys.. I'm getting ready to start working on my first board layout > with a BGA package (FG456). First will be a prototype for sure. > I was just wondering a few things... > > Probably the critical part of my design will be interface to a few > asynchronous SRAMs. > > In a relatively low speed design (buses at 10-25MHz) do I need to > worry about things like termination and trace length on the RAM buses? > Should I dedicate address/data pins to each chip in a shared memory > space, or is it better to daisy chain them on a bus? (It seems to me > that routing will be a little easier if each chip gets its own > lines..) You don't say how many SRAM chips. The first thing to consider in evaluating SI (Signal Integrity) issues without a simulation is to compare the length of the traces to the length of the edges of your signals. The rule of thumb I have seen is that if the rising/falling edges of your signals are six times longer than the length of the trace (round trip) then you don't need to worry with reflections no matter how many chips are in the path. All chips will see essentially the same edges and there will be little ringing. Using an FPGA, you can control the edge rates on the address bus. But on the data bus, you can't control the edge rate from the SRAM chips. If it is too fast (very likely with fast SRAM parts) the data bus will need to be terminated. Terminating multipoint busses is nearly impossible and even a simple two point bi-directional bus is not optimal but can be done using series termination. If you have enough I/O pins on your FPGA to use separate data busses to the SRAMs, you can terminate each bus using a series resistor to match impedance of the driver to the impedance of the trace. This results in a reflection from the receiver, but the receiver sees the proper transition (since it is the point of reflection) and the reflection will not be reflected from the driver. If any other chips are connected in the middle of this signal, they will see a half voltage rise followed by a second rise to the full waveform voltage... not what you want. But then, if you allow time for reflections to settle in your timing analysis, you can ignore the SI issues on the data and address busses and only be concerned about the timing signals like the Write strobe. The address has to be stable by the leading edge of the write strobe and the data has to be stable by the trailing edge. On a read, you simply need to allow some extra time for bus settling before the FPGA clocks the data in. > If I won't be using the innermost IO pins, can I get away with a 4- > layer design, two signal layers and power/ground? Likely, but you will need to consider a number of thing such as your design rules in the layout. > Looking at a Xilinx app note with a suggested escape route for this > package, they have three signal layers with 5 mil width traces, the > third of which I believe I can do without... > And lastly, I guess that I will be needing 1.8 and 2.5V supplies, as > well as 3.3V for all of my I/O supplies.. should these all be routed > in the dedicated power layer? If the layer is mostly covered a plane, > which voltage is supposed to be the plane? 3.3V? Any voltage that will have switching currents on them should have a power plane to optimally filter out the transients... in other words, all of them. What family are you using that requires 2.5 volts as well as 1.8??? I thought the recent stuff was all at 1.2 volts for internal logic and the I/O voltage to match your needs. Are you planning on using 2.5 volts for I/O or are you looking at an old family? Or maybe I'm not remembering correctly??? > And lastly, when connecting I/Os, is there any sensible approach? My > tendency is to want to choose the I/Os so that everything lines up > nicely, but I find it to be a hassle in this case, that in Eagle we > have to connect nets in the schematic first and can't back-annotate > from the board. They why use Eagle? I do my layouts in FreePCB. It doesn't support back annotation actually, but I use forward annotation (updates). I plan my pin swaps and add them to the schematic, reload the new net list and then finish up the routes at the FPGA. It has been a while since I have done this, so it may be trickier than I am remembering. I find it very nice to be able to route with minimal vias. That also helps to minimize the number of layers needed. > Anything else I should be worrying about? If this is your first board layout, leave yourself plenty of time and do a lot of checking of your work as well as checking the tool. There's many a slip twixt cup and lip. I found my first board layout to be a real education... RickArticle: 145261
On 04/02/2010 08:04, rickman wrote: > On Feb 4, 12:22 am, TSMGrizzly<sbatt...@yahoo.co.jp> wrote: >> Hi guys.. I'm getting ready to start working on my first board layout >> with a BGA package (FG456). First will be a prototype for sure. >> I was just wondering a few things... >> >> Probably the critical part of my design will be interface to a few >> asynchronous SRAMs. >> >> In a relatively low speed design (buses at 10-25MHz) do I need to >> worry about things like termination and trace length on the RAM buses? >> Should I dedicate address/data pins to each chip in a shared memory >> space, or is it better to daisy chain them on a bus? (It seems to me >> that routing will be a little easier if each chip gets its own >> lines..) > > You don't say how many SRAM chips. The first thing to consider in > evaluating SI (Signal Integrity) issues without a simulation is to > compare the length of the traces to the length of the edges of your > signals. The rule of thumb I have seen is that if the rising/falling > edges of your signals are six times longer than the length of the > trace (round trip) then you don't need to worry with reflections no > matter how many chips are in the path. All chips will see essentially > the same edges and there will be little ringing. Using an FPGA, you > can control the edge rates on the address bus. But on the data bus, > you can't control the edge rate from the SRAM chips. If it is too > fast (very likely with fast SRAM parts) the data bus will need to be > terminated. Terminating multipoint busses is nearly impossible and > even a simple two point bi-directional bus is not optimal but can be > done using series termination. > You have a lot more experience at this sort of thing than me, Rick, so I'm a little wary of disagreeing with you. But I'm sure you'll tell me if I get something wrong! I don't see that you have to worry about any termination here. With fast enough signal edges, you can get ringing - but that typically will not matter because you don't sample the signals until the ringing has subsided. When the FPGA is driving the signals, you have (as Rick says) controllable rise and fall rates to avoid ringing. If you don't have that, you will want to terminate critical signals like the read and write strobes (or clock, for synchronous rams) to avoid triggering multiple accesses. But other than that, just make sure the data and address lines are stable before the strobes are sent. For reads, it's possible that you will get ringing due to fast edges from the ram chips (though that would require very over-spec'ed ram chips far away from the FPGA), but you time your read sampling for after the lines have settled. Ringing can cause a few problems - the overshoot/undershoot can go outside the voltage range of the pins on the line, it can cause interference for neighbouring signals, you can't read the signal while it is ringing, and it can cause big trouble when connected to edge-sensitive inputs. But most of these are not going to be a problem in your case, I think. If you need to access your rams in parallel, you will need multiple data buses, and perhaps multiple address and control buses - that depends on the application. But if you just want to access one at a time, I'd put them all on the same bus. Routing between the chips will be easy, and you have less lines from the FPGA to worry about. At the speeds you are talking about, you should have no difficulties. > If you have enough I/O pins on your FPGA to use separate data busses > to the SRAMs, you can terminate each bus using a series resistor to > match impedance of the driver to the impedance of the trace. This > results in a reflection from the receiver, but the receiver sees the > proper transition (since it is the point of reflection) and the > reflection will not be reflected from the driver. If any other chips > are connected in the middle of this signal, they will see a half > voltage rise followed by a second rise to the full waveform voltage... > not what you want. But then, if you allow time for reflections to > settle in your timing analysis, you can ignore the SI issues on the > data and address busses and only be concerned about the timing signals > like the Write strobe. The address has to be stable by the leading > edge of the write strobe and the data has to be stable by the trailing > edge. On a read, you simply need to allow some extra time for bus > settling before the FPGA clocks the data in. > > >> If I won't be using the innermost IO pins, can I get away with a 4- >> layer design, two signal layers and power/ground? > > Likely, but you will need to consider a number of thing such as your > design rules in the layout. > > >> Looking at a Xilinx app note with a suggested escape route for this >> package, they have three signal layers with 5 mil width traces, the >> third of which I believe I can do without... >> And lastly, I guess that I will be needing 1.8 and 2.5V supplies, as >> well as 3.3V for all of my I/O supplies.. should these all be routed >> in the dedicated power layer? If the layer is mostly covered a plane, >> which voltage is supposed to be the plane? 3.3V? > > Any voltage that will have switching currents on them should have a > power plane to optimally filter out the transients... in other words, > all of them. What family are you using that requires 2.5 volts as > well as 1.8??? I thought the recent stuff was all at 1.2 volts for > internal logic and the I/O voltage to match your needs. Are you > planning on using 2.5 volts for I/O or are you looking at an old > family? Or maybe I'm not remembering correctly??? > There is a big difference between "optimal" and "good enough". If the design is fairly small and slow, with low currents, then wide traces to the power pins and some capacitors is going to be perfectly sufficient - there is no need for dedicated power planes for each supply. > >> And lastly, when connecting I/Os, is there any sensible approach? My >> tendency is to want to choose the I/Os so that everything lines up >> nicely, but I find it to be a hassle in this case, that in Eagle we >> have to connect nets in the schematic first and can't back-annotate >> from the board. > > They why use Eagle? I do my layouts in FreePCB. It doesn't support > back annotation actually, but I use forward annotation (updates). I > plan my pin swaps and add them to the schematic, reload the new net > list and then finish up the routes at the FPGA. It has been a while > since I have done this, so it may be trickier than I am remembering. > I find it very nice to be able to route with minimal vias. That also > helps to minimize the number of layers needed. > > >> Anything else I should be worrying about? > > If this is your first board layout, leave yourself plenty of time and > do a lot of checking of your work as well as checking the tool. > There's many a slip twixt cup and lip. I found my first board layout > to be a real education... > > RickArticle: 145262
Thanks for the input so far, guys! I will have two SRAM chips and one parallel EEPROM in one memory space, and one additional RAM chip in a separate memory space so I know for sure that that one gets its own dedicated address/control/ data lines. I was just wondering if the signal integrity would be hurt by extra loading in chaining up the ones that are on the same bus, but I had a hunch that at these speeds it wouldn't be such a big problem. And probably I will be using 10ns RAMs (I haven't looked at the rise/ fall times though) and keeping them physically as close as I can get them to the FPGA.. maybe about a centimeter away, tops. Looking at this old Digilent Spartan 3 board I have kicking around, I don't see any termination between the FPGA and the ISSI SRAMs on there, but each chip has its own address and data lines.. I dunno if that's good enough to use as an example or not though. As for the supply voltages, I'll be using a Virtex II, but this is the first time I have started to think about implementing my own board and thus needing to worry about power supplies, and I seemed to remember some of my dev boards in the past having a couple or three different regulators on board, but I didn't really think much about it. Looking at the datasheet though, you're right, Rick, it appears that I just need a single 1.5V supply for core voltage, and 3.3V for VCC_aux and all of my I/O. I should have checked that and had the numbers right before asking, sorry about that. So if I need power planes for both of these voltages, do they each need their own layer or can I arrange it carefully in one layer? Thanks again, SteveArticle: 145263
Dear All,
The solution is really simple. Instead of editing the source file as:
module GetTail(
input [0:0] clock,
input [0:511] inarr,
input [0:31] inpriority,
input [0:31] intail,
input [0:31] innum,
input [0:31] toppriority,
input [0:31] outtail
);
TO :
module GetTail(
input [0:0] clock,
input [0:511] inarr,
input [0:31] inpriority,
input [0:31] intail,
input [0:31] innum,
input [0:31] toppriority,
output [0:31] outtail
);
Simply create a brand new project with the source code module declared
as:
module GetTail(
input [0:0] clock,
input [0:511] inarr,
input [0:31] inpriority,
input [0:31] intail,
input [0:31] innum,
input [0:31] toppriority,
output [0:31] outtail
);
Synthesis works just fine after that.
Also, in response to one of the poster's queries, declare a
register as:
reg [0 : 31] outtailA;
and before the 'always' have:
assign outtail = outtailA;
Where the register outtailA gets assigned to appropriate
output values inside the 'always @ (posedge clock)' .
Thank you for your insightful comments.
On Feb 4, 1:43 am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> In your code you wrote:
>
> > input [0:0] clock,
> > ....
> > always @ (posedge clock)
>
> These are not the same thing. The first usage is a vector with single
> bit number of 0 which is expanded as "clock[0]".
>
> Ed McGettigan
> --
> Xilinx Inc.
Article: 145264rickman <gnuarm@gmail.com> wrote: >... > I'm not clear about your problem exactly. It looks like your system > meets the setup time of the FT2232H chip. The hold time requirement > is 0, so that is met for sure unless you have clock routing problems. > If your clock is on the wrong input, there is not much you can do > about that. I am pretty sure you will not find a real way to meet a > half clock time hold and not blow the setup time. In fact, I don't > really see where you are headed with this. While the idea of half a clock hold time at the output was not my brightest, the question of specifying hold time requirements in general remains. > BTW, where did you get the 5.24 ns value? It's the value form the ds529 datasheet. > My concern is that the > calculation of this time is a bit messy requiring you go add more than > one offset to a base value as determined by the I/O modes. Did you do > all of that? The post layout timing uses this value too (and some adders for IO voltage, rate and drive) Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 145265
Brian Davis <brimdavis@aol.com> wrote: > Uwe Bonnes wrote: > > > > Any other ideas? > > > If the FPGA pin driving the FT2232H WR# pin is within your LHCLK > domain, > how about making WR# the only FAST output pin, and then enable writes > on every other clock cycle. > This would cut your transfer rate to 30 Mbytes/sec max into the > fifo, but give you two clocks of setup for the data lines. Might be an idea. > ( I've never used the FT2232H; the data sheet mentions a max transfer > rate >= 25 MB/s in synchronous mode, and it looks like you have to > monitor the TXE# line to stall writes if the FT2232H isn't ready. ) I now read 28 MB/sec with an adaptation of Micah Dowty fastftdi.c on the PC side and a straight forward approach on the FT2232H side, all outputs fast with high drive and clocked at the posedge with the USBCLK stapped to a GCLK. ... > With a 16.67 ns clock period, starting at the falling edge you'd need > to > delay the data outputs at least 8.33 ns ( to meet the hold time ) but > no > more than 8.33 + ( 16.67 - 11 )= 14 ns to meet the next clock's setup > time. > So you'd need to hold your I/O's switching time to be within a 5.67 ns > absolute window, whilst using slow I/O's with no DLL in the clock > tree. As I wrote in the other posting, this was not the brightest idea. But the question remains, how to specify external hold time requirements with ISE. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 145266
On 29 Jan., 18:50, Antti <antti.luk...@googlemail.com> wrote: > On Jan 29, 7:47=A0pm, EE EE <eengr....@gmail.com> wrote: > you do have to have one output or the flow will fail > > well, design with no IO's could actually be useful, if all data > transfer goes over BSCAN, but the tools require one top level port to > be present Also, a design with only inputs can be used to use DCI to terminate external signals which might be required for external circuitry to work properly. Kolja SulimmaArticle: 145267
On 29 Jan., 20:35, rickman <gnu...@gmail.com> wrote: > =A0So the tools might just > require an input, but I doubt it. This used to be the case a few years ago. The bug has been fixed, but might have been reintroduces later. Designs with only outputs did not work in an earlier ISE version but I had a real world application with only a single output. (An CPLD had to hold OE of a flash at constant high, in a later version there would be logic added to the CPLD, but that was not read yet) Translate failed with the error mesage similar to: Does not fit, your design has 0 inputs but the CPLD you have chosen has only 32 Pins. I opened a web case to research a design that will provide a constant output without the tool optimizing away the dummy input. You could not synthesize output <=3D '1'; in that version. Kolja SulimmaArticle: 145268
TSMGrizzly <sbattazz@yahoo.co.jp> wrote: ... > And lastly, when connecting I/Os, is there any sensible approach? My > tendency is to want to choose the I/Os so that everything lines up > nicely, but I find it to be a hassle in this case, that in Eagle we > have to connect nets in the schematic first and can't back-annotate > from the board. Perhaps the net2ucf.pl Perl script I just uploaded to CADSOFT can help you to generate LOC cobnstrains from an eagle netlist. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 145269
On 2/4/2010 8:23 AM, David Brown wrote: > > You have a lot more experience at this sort of thing than me, Rick, so > I'm a little wary of disagreeing with you. But I'm sure you'll tell me > if I get something wrong! > > I don't see that you have to worry about any termination here. With fast > enough signal edges, you can get ringing - but that typically will not > matter because you don't sample the signals until the ringing has > subsided. > > Ringing can cause a few problems - the overshoot/undershoot can go > outside the voltage range of the pins on the line, it can cause > interference for neighbouring signals, you can't read the signal while > it is ringing, and it can cause big trouble when connected to > edge-sensitive inputs. But most of these are not going to be a problem > in your case, I think. > Dear David, Steve, Going "outside the voltage range of the pins on the line" can break the device. IIRC there are Xilinx appnotes which go into this problem in some detail; powering 3.3V with 3V was something I think they suggested! (See XAPP653) Also, the thing will probably fail any sort on electromagnetic compliance test that you would need to do before you sell this. And you are unlikely to be able to listen to 'The Archers' while this thing is in the room. To the OP, in the absence of micro-vias, I would recommend a 6 layer board. Maybe like this:- signal signal ground ground power/signal signal Keep all the layers as close together as your PCB manufacturer allows and make up the board thickness with the core between the two ground layers. Xilinx on the top. Route the powers, or use copper pours. Try to make room for bypass caps on the back of the board from the FPGA. This stack up will make it very difficult for a beginner to go wrong from an SI point of view, as ground is always near. This is particularly true if you have a nice spread of ground vias tying the two ground planes together. That doesn't mean you shouldn't simulate it with Hyperlynx, but I bet that won't happen! Always examine your ground plane pair at the end of the routing process to make sure you haven't cut any big slots in it with string of vias. Finally, _real_ engineers use DRAMs! ;-) HTH., Syms. p.s. Did I make it clear that the ground is important?Article: 145270
On Feb 4, 7:28=A0pm, Symon <symon_bre...@hotmail.com> wrote: > On 2/4/2010 8:23 AM, David Brown wrote: > > > > > > > You have a lot more experience at this sort of thing than me, Rick, so > > I'm a little wary of disagreeing with you. But I'm sure you'll tell me > > if I get something wrong! > > > I don't see that you have to worry about any termination here. With fas= t > > enough signal edges, you can get ringing - but that typically will not > > matter because you don't sample the signals until the ringing has > > subsided. > > > Ringing can cause a few problems - the overshoot/undershoot can go > > outside the voltage range of the pins on the line, it can cause > > interference for neighbouring signals, you can't read the signal while > > it is ringing, and it can cause big trouble when connected to > > edge-sensitive inputs. But most of these are not going to be a problem > > in your case, I think. > > Dear David, Steve, > > Going "outside the voltage range of the pins on the line" can break the > device. IIRC there are Xilinx appnotes which go into this problem in > some detail; powering 3.3V with 3V was something I think they suggested! > (See XAPP653) > Also, the thing will probably fail any sort on electromagnetic > compliance test that you would need to do before you sell this. And you > are unlikely to be able to listen to 'The Archers' while this thing is > in the room. > > To the OP, in the absence of micro-vias, I would recommend a 6 layer > board. Maybe like this:- > > signal > signal > ground > ground > power/signal > signal > > Keep all the layers as close together as your PCB manufacturer allows > and make up the board thickness with the core between the two ground > layers. Xilinx on the top. Route the powers, or use copper pours. Try to > make room for bypass caps on the back of the board from the FPGA. This > stack up will make it very difficult for a beginner to go wrong from an > SI point of view, as ground is always near. This is particularly true if > you have a nice spread of ground vias tying the two ground planes > together. That doesn't mean you shouldn't simulate it with Hyperlynx, > but I bet that won't happen! Always examine your ground plane pair at > the end of the routing process to make sure you haven't cut any big > slots in it with string of vias. > > Finally, _real_ engineers use DRAMs! ;-) > > HTH., Syms. > > p.s. Did I make it clear that the ground is important? Thanks all, for the good information! This will definitely help. Uwe, I'll take a look at your script, that seems like it could be very handy! Symon, DRAM is out of the question in this design, gotta stick with SRAM.. and it isn't really for sale, it's a custom one-off thing so I don't think I have to worry about compliance tests. I was hoping to keep the cost down a little by skimping on the layers but I'm sure I can afford to go with six layers just fine.. six is what I initially told the boss would probably be happening, I was just wondering if I could get away with four. SteveArticle: 145271
rickman wrote: > Can anyone confirm or dispute it the relative quality of Actel tools? > Am I mistaken about them? I am speaking only about my own personal point of view of mine... and under Windows (have not yet had time to re-try under Fedora) The Actel tools take a while to get used too, like most big SW suites. It's its own world... It is not particularly terrible, I can do mostly what I want, inside the bounds of reality and the target chip's capacity. I have not tried to "hack" things because I don't want to be dependent on a specific too, I do my stuff in VHDL and add a constraint file (which can be a bitch is a few situations but not a real limit). The latest version of Libero seems OK, it's not groundbreaking but I sense some care for user friendliness (which is a whole different concept in itself if the FPGA world ;-D) When badly blocked, I could contact my local FAE and even a local Actel office. The usefulness of the online reporting/case tool is ... mitigated but can be tried if a project is badly screwed. Oh, and comp.arch.fpga is very helpful too ;-) So I can say that "Actel works for my case" and I'm fine with it. It just takes a lot of time to get used to the rules and design of this particular "world", so it's usual to ask impossible or difficult things when learning. Later, one does design things around the chip's capabilities instead of the contrary, and it goes smoothly (after a few iterations ;-D) I'm curious to read other people's impressions... > Rick yg -- http://ygdes.com / http://yasep.orgArticle: 145272
>Thanks for the input so far, guys! > >I will have two SRAM chips and one parallel EEPROM in one memory >space, and one additional RAM chip in a separate memory space so I >know for sure that that one gets its own dedicated address/control/ >data lines. >I was just wondering if the signal integrity would be hurt by extra >loading in chaining up the ones that are on the same bus, but I had a >hunch that at these speeds it wouldn't be such a big problem. > I suggest checking the data bus turn-off (->Z) time of the EEPROM. It might be rather long, meaning that an EEPROM read followed by an SRAM access causes data corruption. If it is too long, either put an extra buffer with fast turn-off on the board, or else use dedicated data signals and mux it in the FPGA. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145273
On 30 Jan., 09:59, Antti <antti.luk...@googlemail.com> wrote: > there is no need to test anything with empty design :) I just prepared a golden empty reference netlist and volunteer to perform a manual equivalence check on your emtpy netlist for 50$. KoljaArticle: 145274
dlopez wrote: > Hi, > There seems to be an endless numbers of way to mess up CRC calculations! yes :-) > Has anyone come up with the right way to match a software calculated CRC > with whay comes out of either the 'easics' core or the 'outputlogic' core > (both yielding the same result in simulation). write your own HDL code. > Here are questions: > -should I reverse or inverse the input data? What order? > -should I reverse or inverse the output data? What order? are you using a Galois or Fibonacci configuration ? :-D that makes 8 combinations, maybe you should try them all ? when correctly done (automated), it does not take much time. > I'm using > CRC-32: 0x04C11DB7 = x32 + x26 + x23 + x22 + x16 + x12 + > x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 ok, CRC32 in bit-serial configuration is easy, simple and fast, you need about 32 bits of bit-shifting storage with about 15 XOR2 (or 5 LUT4). have you read http://www.ross.net/crc/download/crc_v3.txt ? it is HIGHLY recommended and easy to read. > Thanks good luck, CRCs can be disturbing at first but it's not that difficult in the end. > Diego yg -- http://ygdes.com / http://yasep.org
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