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
Martin Euredjian <0_0_0_0_@pacbell.net> wrote: : Working with the Floorplanner tonight (5.2, latest service pack) I had the : pleasant experience of having the software mangle my extensive UCF file for : no good reason. All floorplanning constraints being used are area : constraints except for hard locations for such things as multipliers and : SelectRAM. : Thankfully a culture of frequent backups saved the day (night) with a bit of : work. : This leads me to ask: Are there any undocumented gotcha's I should look out : for? : Also, is there a way to have Floorplanner write more sensible area : constraints? Wildcards are allowed in the instance specification, but it : doesn't seem to know how to use them. So, if I want to allocate an area to : the "input_fifo*" instance I get 100 lines of "INST" specifications instead : of a simple: : INST "input_fifo*" AREA_GROUP = "grp_input_fifo"; : Is there a way to convince it to do it right? In my opinion, the concept of a single UCF file is flawed. Timing constraints, pin assignments and other constraints should be separated in different files. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 58426
"Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: > In my opinion, the concept of a single UCF file is flawed. Timing > constraints, pin assignments and other constraints should be separated in > different files. I can agree with that. I've also had the experience of the UCF file being removed from the project without so much as a warning. Of course, the first thing that happens is that your pin assignments (I/O standards, etc.) are gone. Given that the tools are exceedingly happy to assign I/O as they see fit. If you are not awake through all of this you might just fire-up IMPACT and send that bit stream down the extra-happy JTAG connection. Of course, all bets are off when the thing comes out of program mode and you might just blow an expensive FPGA into useless silicon before you can figure out what happened. So, yes, I can agree with what you say. Pin assignments should be regarded as sacred. And the tools should not fail if, at various stages of development, no logic is attached to the design's I/O (I know this can be overriden). ...at 4:20 AM some of these things cese to be funny real fast. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 58427
In fact I'm using one more byte added to the DVB codeword to provide synchronism and signalling. This system is design for a point-to-point RF link and must be continuous, I don't know if a burst transmition could be allowed. Thanks Ivan "Kevin Neilson" <kevin_neilson@removethistextcomcast.net> wrote in message news:<eyhTa.118994$ye4.87015@sccrnsc01>... > "Ivan" <ivansimoes@msn.com> wrote in message > news:4746b99b.0307221230.53adc209@posting.google.com... > > I'm design a FEC scheme using Reed-Solomon and FPGA Cyclone (Altera). > > The input clock is 2.048MHz and the output must be (205/188)*2.048MHz > > (~2.233191MHz). The problem is in the increase clock rate at the > > output. The internal PLL works only whit frequencies above 15MHz and > > the factor 205/188 can't be achieve too. I think increase rate is a > > commom problem in channel coding application but I do not have any > > success searching related topics on internet or on books. For example, > > in celular a initial bit rate of 4.8kbps is increased to ~70kbps at > > the end of coding process, and there are a lot of intermediary rates > > (9.6kbps,32kbps etc). > > > > Using a external PLL was the first idea but I'd like to implement all > > the scheme in fpga. My actual aproach is to use a digital NCO (derived > > from a sample clock of 200MHz) with the central frequency in > > 2.233191MHz and a loop control related with the input clock. In the > > loop control the input clock and output clocks are conected to > > counters, when the input counter is 188 the output counter is sampled > > and the count value expected is 205, if it is false a new numeric > > control is applied to the NCO to correct the frequency. > > > > I dont know if it can works well and if anybody have any suggestion or > > idea I'd appreciate. > > > > Thanks > > > > Ivan > > Ivan, > Do you mean 204/188? That's the normal RS code rate for DVB. You can use a > digital PLL that will track the input clock such that the NCO vector spins > at 204/188 * input_clk, as long as you don't mind the 5ns jitter of the > output clock. > > If this is a DVB modulator, you may have successive stages that change the > code rate (like a trellis coder) and it's best just to clock only the final > stage at the required rate, and let each stage fetch data irregulary from > the previous stage as it is required. > > Another method is to have a fixed output clock that runs faster than the > required rate of 204/188*input_clock. When the input FIFO underflows, a > null packet is transmitted while the input FIFO fills again. > -KevinArticle: 58428
Hi all. I have a problem with Altera's Nios : I've added the Interface To User Logic, which is supposed to be interface to the SDRAM controller/arbiter. I'm using this interface instead of NIOSes SDRAM controller because I have several devices that are accessing same SDRAM, and I have special arbiter for it. So the interface is supposed to connect NIOS to that arbiter. When Nios writes to SDRAM, it's supposed to set the "chip_select" and "write" bits, and supply the address and data to write. Then NIOS is supposed to wait for the "ready" bit from the arbiter, and only then NIOS should end the transaction by turning off the "chip_select" bit. The problem is that NIOS doesn't wait for that "ready" bit - it's just turning off the "chip_select" bit, thus the transaction is concidered by the arbiter as aborted. How can I make NIOS to wait for the "ready" from the arbiter? I think I've tryed every signal there : "dataready", "dataready_n", etc... Or maybe there is a way to configure NIOSes SDRAM controller to support two NIOS CPUs instead of using that external arbiter? Has anyone tryed something like this? Thanks in advance, Yevgeny.Article: 58429
Jon Masters wrote: > Switching back to real mode causes a lot of problems at the moment - > start_kernel turns off the MMU to setup exception handlers and so on[0]. > When this happens it does the usual rfi trick to switch IR|DR off in the > MSR and jump to the next instruction which generates a Machine Check. It now looks as though Machine Check is being generated every time I do an rfi from the point I was at but disabling MSR_ME works ok so I believe these Machine Check exceptions may be erroneously generated due to something with the hardware definition - any suggestions are welcome? Jon.Article: 58430
Hi, The chip revision is 20010820 which I also recently discovered has a nice list of errata. I especially like CPU_210 and the uTLB one. CPU_210 issue rules out a lot of standard PowerPC atomic operation sequences accessing system memory while the latter affects TLBs. Jon.Article: 58431
Hi at all, how can I automaticly generate an MCS-file with the WebPack 5.2 (SP2) on every syntheziser-run? in the old WebPack 4.x there is a program that does it automticly on every syntheziser-run Thanks for help ErikArticle: 58432
I think that what you are asking for is the "Ratsnest". When the ratsnest
option is turned on, the tool will display all the connections from a
selected cell (CLB or IOB), to all other cells connected by nets.
For some reason (that I never understood) there are TWO mechanisms to turn
on ratsnest view, and both of them must be on to actually see the ratsnest.
The more obvious one is the icon in the toolbar, which identifies itself as
"Toggle Rubber Bands". It is an icon with one dot on the left connected to 4
dots on the right by magenta lines. The less obvious one is done from the
menus
Edit->Preferences...
Select the Ratsnest tab
Check the "Display nets connected to selected logic"
With this option selected, and the Toggle Rubber Bands depressed, you will
see the ratsnest.
Avrum
"Atif" <atif@kics.edu.pk> wrote in message
news:6a0a3f23.0307230041.79dc6b08@posting.google.com...
> Hello all,
> I'm using xsa100 (xc2s100) board with registered evaluation version of
> Xilinx ISE5. I'm a newbie to this. I'm following the instructions in
> the manual "Introduction to webpack 4.1 for FPGAs" downloaded from
> http://www.xess.com/appnotes/webpack-4_1-fpga.pdf.
>
> I've written a code in Verilog for leddec (7 segment display). Then I
> follow the steps written in the manual. For the step in manual "to
> constraining the Fit", I can not find "Edit implantation constraints
> (Constraint editor)" in the "User Constraints" process to assign the
> FPGA pins to my I/Os. But I find "Assign package pins" in the "User
> constraints" of ISE5. On clicking this, it says that there is no
> Implementation constraint file. I make a new one by Project<-New
> Sourse<-Implementation constraint file and add this to current
> project. Now "Assign package pins" works. I assign the I/O signals to
> the FPGA pins as written in the manual.
>
> Everthing is allright so far. But in the step of "viewing the chip",
> when I click "view/edit Placed design (Floor planner)", it shows me
> the CLB's and Inputs and output pads.
> But inpouts and outputs are not associated with CLB's. As I click CLB,
> it should show the I/Os associated with it in shape of arrows from CLB
> to all the I/Os. But This does not happen.
>
> Can anyone please help me telling me where is the error and how to
> remove it?
>
> One more question, at each step, ISE5 gives me the warning that its an
> evaluation version. Will this warning create a problem anywhere in the
> design on loading and testing it to FPGA?
>
> Sorry for bothering such a huge textl.
>
> Regards
>
> Atif Nadeem
> Research Associate
> Al-Khawarizmi Institute of Computer Science,
> University of Engineering & Tech., Lahore
> Pakistan, 54890
Article: 58433Allan, I considered that obvious. All hell breaks loose everywhere when routing delays exceed the clock period. Peter Alfke =============================== Allan Herriman wrote: > > On Tue, 22 Jul 2003 09:21:34 -0700, Peter Alfke <peter@xilinx.com> > wrote: > > >Yes, you have to be paranoid. But there is no problem with crossing the > >clock domain boundary using a Grey signal. > > To be more precise: there is no problem with crossing the clock domain > boundary using a Gray signal, provided that the maximum routing skew > is less than the period of the source clock. > > Regards, > Allan.Article: 58434
Nyquist has nothing to do with this, and metastability ( with or without exclamation marks) is not an issue when you move a Grey-coded register value across the clock boundary. Peter Alfke ======================== Andrew Paule wrote: > > Just remember nyquist - if you forget - metastability!!!!!!!!!! > > Andrew Paule > >Article: 58435
On Wed, 23 Jul 2003 10:55:03 GMT, "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote: >"Ray Andraka" <ray@andraka.com> wrote: > >> The automatic placment algorithms, while better than in the past, still >suck. I >> do a large amount of explicit placement using a structural hierarchy. The >> relative placements (in the form of RLOCs) are in the code, and these are >built >> up hierarchically. Some examples of the floorplans can be seen on the >gallery >> page of my website (thanks Phil Freidin for that idea). > >Could I bother you to provide an example of how to do this? Are you saying >that you locate placement constraints within the HDL modules themselves? >How exactly are they "built up hierarchically"? For simple placement, see the following: http://www.fpga-faq.com/FAQ_Pages/0011_Verilog_RLOCs.htm http://www.fpga-faq.com/FAQ_Pages/0010_VHDL_RLOCs.htm What Ray is writing about is more complex, and probably can only be done in VHDL, as it requires directives like generate to build large sophisticated designs. Hopefully he will post an example of his more interesting code. >I searched Google for a post from Phil Freidin on the subject but failed to >locate anything applicable. Ray was thanking me above for the idea of placing floorplanning pictures on his web site, which I have been doing for many years. You can find mine at: http://www.fliptronics.com/gallery.html and his at: http://www.andraka.com/gallery.htm >Thanks, A fairly dated tutorial on floorplanning exists at: http://www.fliptronics.com/floorplanning1.html These days, what I called floorplanning, is now called placement, and the term floorplanning is now used to describe techniques such as area constraints. Philip Philip Freidin FliptronicsArticle: 58436
I have trouble remembering so it's always nice to see the reference once more. As noted in http://www.nist.gov/dads/HTML/graycode.html , "The codes were first patented by Frank Gray, a Bell Labs researcher, in 1953." The code is a "Gray code" as opposed to a "gray code" or "grey code" because it's named after the inventor. The capitalization is because it's a proper name. Personally, I like it much better than the "Frank code" alternative. The original patent number referenced in other sources is 2632058 for those who'd like to peruse the uspto.gov database. (I don't have the proper TIFF viewer handy to see it for myself) Enjoy! - John_HArticle: 58437
Theoretically, the delay differences of the implemented CRC circuit are based on the maximum number of XOR levels of an input but nothing to do with the total XORs in the implementation. But when I compared the synthesis results of my design, the same number of XOR levels get the different results if the total number of XORs are different. I don't know why, any one can help me to explain this? If the above situation is correct, then I don't think you can get a reasonable result for CRC-32. Since the number of XORs is dramatically large compared with the CRC-16 implementation. So even if you only have maximum 78 XORs per input, the speed will be very low, since the total number of XOR increases. "Avrum" <avrum@REMOVEsympatico.ca> wrote in message news:<roBSa.539$1I5.79766@news20.bellglobal.com>... > You can do a LOT more than that at 100MHz - we have done CRC16 at 128bits > per cycle at over 100MHz with no trouble at all (12.8Tbps) in a Virtex-II, > slowest speed grade. For a CRC16 of 128 bits, each CRC bit is a function of > a subset of the 128bits coming in and the 16 CRC bits from the previous > calculation - the most complex bit contains about half the terms (so is the > XOR of about 70 bits). Thus, the complete CRC calculator is 16 XOR trees > each with less than 70 inputs. > > A CRC 32 would only be slightly slower, since the largest term would have > slightly more inputs (probably closer to 78), so you would have 32 XOR trees > each with less than 78 inputs - it would be slower, but not much slower. It > would, however, consume more than twice the resources (which aren't tiny). > > Avrum > > > "Kevin Neilson" <kevin_neilson@removethistextcomcast.net> wrote in message > news:7DqSa.90603$wk6.25402@rwcrnsc52.ops.asp.att.net... > > Unsing lookup tables for CRC in an FPGA isn't really worthwhile because > it's > > really easier just to do it with hardware, and it takes less logic. If > you > > are only processing one bit per cycle, then both CRC32 or CRC64 have > pretty > > trivial implementations. You can run this type of circuit over 200MHz > > easily. If you are processing more than one bit per cycle, it becomes > more > > difficult and you incur more levels of logic, but for a CRC of only five > or > > six bits, I would estimate you could still process one byte per cycle at > > well over 100MHz (800Mbps). Some tricks can increase that speed. > > -Kevin > > > > "Jimmy Zhang" <crackeur@comcast.net> wrote in message > > news:WTnSa.89454$OZ2.19172@rwcrnsc54... > > > Hi, > > > > > > I was wondering if anyone can help answer a few questions on CRC. > > > > > > Does FPGA use table lookups to do CRC calculation? Does it help to do > so? > > > > > > Also is CRC64 considerably more expensive than CRC32 using FPGA > > > implementation? What is the reasonable performance number for CRC32 or > CRC > > > 64? > > > > > > Thanks, > > > Jimmy > > > > > > > > > >Article: 58438
Hi Jim,
Close, but no cigar! When I put the syn_keep on toggle, the FF
data_int1 problem is cured! Sadly, Synplify then ignores my
syn_direct_enable directive on the enable to the 4 counter FFs that
make up toggle!
Any further thoughts? BTW, my interim work around is to make
toggle a std_logic_vector and pick out bits in my code. This seems to
work thus far.
Thanks for your help on this, it's much appreciated!
cheers, Syms.
p.s. This is what I added to the code:-
attribute syn_keep: boolean;
attribute syn_keep of toggle : signal is true;
"Jim Robinson" <jim@synplicity.com> wrote in message news:<mpjTa.27433$Nf.71843@sea-read.news.verio.net>...
> Symon,
>
> You are using the syn_direct_enable directive correctly.
> As you noticed, you achieved the desired behavior on the
> data_int2 Flip Flop, but data_int1 FF was not correct.
>
> Synplify seems to be loosing the direct_enable when
> it is evaluating the integer expression toggle=0 along with
> the enable expression.
>
> It is possible to work around this problem by placing a "syn_keep"
> directive on toggle. The syn_keep directive creates an
> optimization boundary and this prevents Synplify from optimizing
> toggle together with enable and thus produces the results
> you expected. Your test case with my modifications follows
> below. I realize the RTL posted on this message is just a
> test case, but I assume that a similar work around can be used
> on your actual design. If you need assistance getting this
> to work on your design please do not hesitate to contact me
> or any of our Corporate Application Engineers at
> support@synplicity.com.
>
> Obviously this is a bug in Synplify and I have filed bug # 107936.
> This will be fixed in a future release. Please let me know if the
> work around will solve your problem in the short term and
> how urgently you require a fix to be incorporated into the tool.
>
> Best Regards,
> Jim Robinson
> jim@synplicity.com
>
>
>
>
> library IEEE;
> use IEEE.STD_LOGIC_1164.all;
>
> entity direct_enable_test is
> port (
> signal res_n : in std_logic; -- General reset.
> signal clock : in std_logic; -- clock 350MHz
> signal toggle_in : in integer range 0 to 15; -- toggle value
> signal data : out std_logic -- data
> );
> end direct_enable_test;
>
> architecture direct_enable_test_arch of direct_enable_test is
>
> signal enable : std_logic;
>
> signal data_int1 : std_logic;
> signal data_int2 : std_logic;
> signal toggle : integer range 0 to 15; -- toggle value
> attribute syn_direct_enable: boolean;
> attribute syn_direct_enable of enable : signal is true;
> attribute syn_keep: boolean; -- Workaround
> attribute syn_keep of toggle : signal is true; -- Workaround
>
> begin
>
>
> data <= data_int1 or data_int2;
>
> process (res_n, clock)
> begin
> if (res_n = '0') then
> enable <= '0';
> toggle <= 0;
> elsif rising_edge (clock) then
> enable <= not enable;
> if enable = '1' then
> toggle <= (toggle + 1) mod 16;
> end if;
> end if;
> end process;
>
> process (res_n, clock)
> begin
> if (res_n = '0') then
> data_int1 <= '0';
> elsif rising_edge (clock) then
> if enable = '1' then
> if toggle = 0 then
> data_int1 <= not data_int1;
> end if;
> end if;
> end if;
> end process;
>
> process (res_n, clock)
> begin
> if (res_n = '0') then
> data_int2 <= '0';
> elsif rising_edge (clock) then
> if enable = '1' then
> if toggle_in = 0 then
> data_int2 <= not data_int2;
> end if;
> end if;
> end if;
> end process;
>
> end direct_enable_test_arch;
Article: 58439Thanks. So lets remember: "Gray with an a!" Honor where honor is due. Peter Alfke JArticle: 58440
"Barry Brown" <barry_brown@agilent.com> wrote in message news:<1058824681.854644@cswreg.cos.agilent.com>... > A few more details I should have mentioned: > write clock is 40 MHz > read clock is 75 MHz > I only need the "number of words in FIFO" count on the read clock side > > Here is what I have been thinking - > Gray counters for read and write addresses. Re-clock the gray write address > with the read clock, then convert it back to binary. Subtract the read > address from the re-clocked write address (both in binary), to get the > number of words in the FIFO. It seems that if I re-clock the write address > while it's in gray code, I should only have a one count ambiguity. > > Anyone see a flaw, or have a better idea? > It's far simpler than this. Everything is binary. Reclock LS bit of the write address with the read clock (3 consecutive FFs). Detect edges (XOR 2nd and 3dr FFs - the 1st is here to fight metastability). On edges increment "number of words in FIFO" count. On read pulse decrement. When both - don't change. That's about all. 11.6ns difference in the clock periods is more than enough for reliable edge detection. The count has a latency of 2-3 read cycles relatively to the "true" count, but any metastability-safe design would suffer a similar latency. Typically it doesn't matter. You can cut the latency by one clock by combinatorial summation of the count with the output of the edge detector. The only issue I see with this design - after the reset you should wait one write clock before pushing 1st data in.Article: 58441
Martin Euredjian wrote: > > Another related question. > > Is there a way to area-constrain the logic corresponding to an HDL module > and then have the tools take an iterative approach to getting the best > placement (say, timing and data-path alignment) within that area? I don't know about the iterative placement approach, but you can use area location constraints. But most likely you will do better with relative location constraints within your critical modules. Then the tool can put the module anywhere it likes, but the high speed paths within the module will likely find the better routing provided by your hand placement. -- 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: 58442
Allan Herriman wrote: > > On Wed, 23 Jul 2003 04:01:10 -0400, rickman <spamgoeshere4@yahoo.com> > wrote: > > >I am creating a new design in Quartus using VHDL. It has been a long > >time since I have used VHDL and so I am relearning a lot of the issues > >with the language. I have found a couple of cases where the Quartus > >compiler either flagged an error that had nothing to do with the problem > >in my source code or did not flag an error and produced wrong logic. > > > >The problem I am having now is that my design is not being synthesized > >fully or large parts are being optimized away. I have checked the > >generated equations as best I can and compared to my source and can not > >find a reason that this should be happening. > > > >I have a ticket open with support, but they have not even asked me for > >my code yet and I doubt that we will get much going until that happens. > > > >I started this post about 10 hours ago and had to leave before I > >finished. When I got back I continued working on the problem before I > >completed the message. I finally found the problem. Seems that if you > >have a mismatch in the size of the vectors in an assignment or > >comparison, the software does not complain, it just produces some bad > >logic. Mainly it takes out all the subsequent logic. Trying to sort > >through a design at the equation level and figure out what part is > >missing and what part remains is not a simple task. > > Your simulator would have picked up the error straight away during > either compilation or elaboration. Did you simulate your design? No, I did not simulate the design because it is nowhere near complete. I have been away from hands on VHDL design and am not very familiar with the Quartus tool. So I am building my design up in pieces and trying to verify that it is correctly synthesized before I move on to the next piece. It never occurred to me that I needed to run a simulation to verify that my code would synthesize correctly. Perhaps I need to dig into that next. -- 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: 58443
I'm not sure I understand everything you are trying to say, but the point is that the number of inputs to the various bits of the CRC does not continue to increase beyond a certain point. First you can divide the inputs into two groups, the feedback from the last value of the CRC and the inputs from the data stream. This is important to understand since the feedback bits can not be pipelined, while the data inputs can. If you are only calculating a small number of bits at a time, the maximum number of inputs is about equal to the number of bits you are calculating. An example is a four bit calculation of a CRC. Mostly the sparse feedback and input bits will not overlap much so that the number of inputs to each bit will be about four with some at five or six. But once you get to large numbers of input bits being calculated in one operation, you will find that many of the bits start to cancel themselved out of a given bit since an XOR of an item with itself an even number of times is equal to '0' and has no effect on that bit. An odd number of inputs of the same bit to an XOR operator is the same as a single bit. So in CRC computations with large numbers of bits being input in one clock cycle, the number of inputs tends toward about half the inputs and half the feedback bits being used as inputs at each CRC bit being calculated. If you are calculating 64 bits at one time the change from a CRC-16 to a CRC-32 will only change the number of inputs to each bit from about 72 to 80 or by about 8. Of course some bit computations will be a bit more than half and some a bit less than half, but they don't vary a lot from the average. Alex wrote: > > Theoretically, the delay differences of the implemented CRC circuit > are based on the maximum number of XOR levels of an input but nothing > to do with the total XORs in the implementation. But when I compared > the synthesis results of my design, the same number of XOR levels get > the different results if the total number of XORs are different. I > don't know why, any one can help me to explain this? > > If the above situation is correct, then I don't think you can get a > reasonable result for CRC-32. Since the number of XORs is dramatically > large compared with the CRC-16 implementation. So even if you only > have maximum 78 XORs per input, the speed will be very low, since the > total number of XOR increases. > > "Avrum" <avrum@REMOVEsympatico.ca> wrote in message news:<roBSa.539$1I5.79766@news20.bellglobal.com>... > > You can do a LOT more than that at 100MHz - we have done CRC16 at 128bits > > per cycle at over 100MHz with no trouble at all (12.8Tbps) in a Virtex-II, > > slowest speed grade. For a CRC16 of 128 bits, each CRC bit is a function of > > a subset of the 128bits coming in and the 16 CRC bits from the previous > > calculation - the most complex bit contains about half the terms (so is the > > XOR of about 70 bits). Thus, the complete CRC calculator is 16 XOR trees > > each with less than 70 inputs. > > > > A CRC 32 would only be slightly slower, since the largest term would have > > slightly more inputs (probably closer to 78), so you would have 32 XOR trees > > each with less than 78 inputs - it would be slower, but not much slower. It > > would, however, consume more than twice the resources (which aren't tiny). > > > > Avrum > > > > > > "Kevin Neilson" <kevin_neilson@removethistextcomcast.net> wrote in message > > news:7DqSa.90603$wk6.25402@rwcrnsc52.ops.asp.att.net... > > > Unsing lookup tables for CRC in an FPGA isn't really worthwhile because > > it's > > > really easier just to do it with hardware, and it takes less logic. If > > you > > > are only processing one bit per cycle, then both CRC32 or CRC64 have > > pretty > > > trivial implementations. You can run this type of circuit over 200MHz > > > easily. If you are processing more than one bit per cycle, it becomes > > more > > > difficult and you incur more levels of logic, but for a CRC of only five > > or > > > six bits, I would estimate you could still process one byte per cycle at > > > well over 100MHz (800Mbps). Some tricks can increase that speed. > > > -Kevin > > > > > > "Jimmy Zhang" <crackeur@comcast.net> wrote in message > > > news:WTnSa.89454$OZ2.19172@rwcrnsc54... > > > > Hi, > > > > > > > > I was wondering if anyone can help answer a few questions on CRC. > > > > > > > > Does FPGA use table lookups to do CRC calculation? Does it help to do > > so? > > > > > > > > Also is CRC64 considerably more expensive than CRC32 using FPGA > > > > implementation? What is the reasonable performance number for CRC32 or > > CRC > > > > 64? > > > > > > > > Thanks, > > > > Jimmy > > > > > > > > > > > > > > -- 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: 58444
So ... it sure sounds like I'm trying to swim upstream. Is there a constraint that could cause data paths to be aligned better or is it futile to even try? Take a pipe consisting of four eight-bit registers (as a simple example). Can one over-constrain? Set a low maximum delay for the nets? Take an FIR module, for example. Are we doomed to hand-placement of such a beast? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "rickman" <spamgoeshere4@yahoo.com> wrote in message news:3F1EEB4E.5B323FCA@yahoo.com... > Martin Euredjian wrote: > > > > Another related question. > > > > Is there a way to area-constrain the logic corresponding to an HDL module > > and then have the tools take an iterative approach to getting the best > > placement (say, timing and data-path alignment) within that area? > > I don't know about the iterative placement approach, but you can use > area location constraints. But most likely you will do better with > relative location constraints within your critical modules. Then the > tool can put the module anywhere it likes, but the high speed paths > within the module will likely find the better routing provided by your > hand placement. > > -- > > 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 >Article: 58445
Hi Aurash,, Aurelian Lazarut wrote: > John, > Try: > promgen -help ah ha! thanks for that. Perhaps a X-ref from the iMPACT doco to PROMGEN might be in order for a future release. Thanks again, John > > Cheers, > Aurash > > John Williams wrote: > > >>hi folks, >> >>I'm trying to convert a .bit file into an MCS file suitable for putting >>into a configuration PROM. I can do this just fine with the GUI, via >>the following path of steps >> >>Prepare Configuration Files -> >>PROM file -> >>Choose target (Serial PROM, MCS format etc) -> >>Add Device XC18V04 -> >>Add File (download.bit) -> Finish >> >>I can then download this file to the PROM, and it will configure the >>FPGA and so on. >> >>However, I want to automate this procedure into an iMPACT batch file. >>The doco is a bit obtuse on the subject - there are plenty of batch mode >>examples for configuring devices, but none I could find for generating >>PROM files. >> >>I've got this far: >> >>$ impact -batch >> >setmode -pff >> >setsubmode -pffserial >> >addpromdevice -p 1 -name xc18v04 >> >>However, if I now try to use assignfile, and give it the input bitfile: >> >assignfile -p 1 -file download.bit >> >>it bombs with a fatal error. >> >>I'm figuring I'm close, just need to >> >>(a) assign a bit file that goes into the prom file >>(b) generate the file >> >>There's the 'generate' command but that also bombs, presumably because I >>haven't properly assigned a bitfile yet. >> >>Can anyone point me in the right direction? >> >>Thanks, >> >>John > > > -- > __ > / /\/\ Aurelian Lazarut > \ \ / System Verification Engineer > / / \ Xilinx Ireland > \_\/\/ > > phone: 353 01 4032639 > fax: 353 01 4640324 > > -- Dr John Williams, Research Fellow, Reconfigurable Computing, School of ITEE University of Queensland, Brisbane, Australia Ph : (07) 3365 8305Article: 58446
Basically, the lowest level of your hierarchy, at least the parts you want to
place, are xilinx unisim primitives. Using the VHDL generate construct allows
you to describe the logic and placement for one bit, and then have that
replicated in a sort of step and repeat fashion to build up your bottom level
macros. Those macros can then be used in a larger design by putting RLOCs on
the macro. The following is the generate loop to make a registered adder. That
adder component can then be used in the next level up and placed by putting an
RLOC attribute on the component following the same format as inside the generate
loop. The adder is a reusable component that can then be used in many designs
without having to change anything. Likewise, the next level up might be a
filter generate macro or something like that that builds a placed component that
can then be used in a higher level design.
L:for i in 0 to width-1 generate
constant rc_str : string := "R" & itoa( origin -(i/2)) & "C0" & ".S" &
itoa(slice mod 2);
constant xy_str : string := "x0y" & itoa((i/2)-origin) ;
constant rloc_str : string := pickstring(virtex,rc_str,xy_str);
signal l,s,qr,qs: STD_LOGIC;
attribute BEL of U1:label is bel_lut(i mod 2);
attribute BEL of U3:label is bel_xor(i mod 2);
attribute BEL of U4:label is bel_ff(i mod 2);
attribute RLOC of U1 : label is rloc_str;
attribute RLOC of U2 : label is rloc_str;
attribute RLOC of U3 : label is rloc_str;
attribute RLOC of U4 : label is rloc_str;
begin
U1: fmap_xor2 port map(
a=> ax(i),
b=> bx(i),
z=> l);
U2: MUXCY port map (
O => cy(i+1),
CI => cy(i),
DI => ax(i),
S => l );
U3: XORCY port map (
O => s,
CI => cy(i),
LI => l );
U4: FDRE port map (
Q => q(i),
D => s,
R => lcl_rst,
CE => lcl_ce,
C => clk );
end generate L;
Martin Euredjian wrote:
> "Ray Andraka" <ray@andraka.com> wrote:
>
> > The automatic placment algorithms, while better than in the past, still
> suck. I
> > do a large amount of explicit placement using a structural hierarchy. The
> > relative placements (in the form of RLOCs) are in the code, and these are
> built
> > up hierarchically. Some examples of the floorplans can be seen on the
> gallery
> > page of my website (thanks Phil Freidin for that idea).
>
> Could I bother you to provide an example of how to do this? Are you saying
> that you locate placement constraints within the HDL modules themselves?
> How exactly are they "built up hierarchically"?
>
> I searched Google for a post from Phil Freidin on the subject but failed to
> locate anything applicable.
>
> Thanks,
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_" = "martineu"
--
--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: 58447Hi, So we are looking to implement some functionality that we have done in NPUs in the past into a Xilinx Virtex2Pro family (small space and less power). These parts are quite expensive right now (up to $1500 a piece). Our build timeframe is starting next year, carrying out into 2006/2007. When you add up the cost of product- the budget is nearly consumed completely by the FPGAs. The question is how much do you usually expect FPGA prices to fall in a given year. For example, would a guess of a 15% drop in the first year followed by a 30% fall in the second year be a good stab? 20% a year? I just need to fill out some numbers to make some bean counter happy. Anyone take a look at what has historical been the price drops? Thanks, M ScottArticle: 58448
nahum_barnea@yahoo.com (Nahum Barnea) wrote in message news:<fc23bdfc.0307080518.712eca43@posting.google.com>...
> Hi.
>
> My company is working on a xc2v8000 design, I expect it to be almost
> fully utilized (85%).
>
> I feel that our computing power is not sufficient.
>
> I am using Sun Ultra-80 with 4 GB memory.
>
> fpga_editor and floorplanner take a lot of time.
> P&R flow takes a lot of time.
> I read in Xilinx docs that the recommendation for xc2v8000 is 3 GB
> memory.
>
>
> Do you have from your experience additional recommendations, such as
> graphic card type, Processor, memory, or a brand name computer that
> you successfully use?
>
>
> ThankX
> NAHUM
I have a design using the XC2V6000 that uses 66% of the chip's
capacity (23,000 slices out of 33,792).
I am using the P4 2GHz PC , Windows XP PRO, with 1GB DDR SDRAM.
It takes 5 hours to synthesize, and 1 hour to place and route.
I am sure that you are OK with the SUN processor. I have had some
designs use 2GB of virtual memory.
Bill Hanna
Article: 58449Your question can best be answered by a Xilinx salesperson, or most likely a Sales Representative. If they cannot get you the answer dirctly, they contact the factory. They will love to talk to you and give you a quote with "budgetary figures". They really are your friend, because they have a vested interest to make you succeed. That is the only way they will get paid. Do you have such a sales contact? Peter Alfke, Xilinx Applications ================================ MS wrote: > > Hi, > So we are looking to implement some functionality that we have done in > NPUs in the past into a Xilinx Virtex2Pro family (small space and less > power). > > These parts are quite expensive right now (up to $1500 a piece). Our > build timeframe is starting next year, carrying out into 2006/2007. > When you add up the cost of product- the budget is nearly consumed > completely by the FPGAs. > > The question is how much do you usually expect FPGA prices to fall in > a given year. For example, would a guess of a 15% drop in the first > year followed by a 30% fall in the second year be a good stab? 20% a > year? I just need to fill out some numbers to make some bean counter > happy. Anyone take a look at what has historical been the price > drops? > > Thanks, > M Scott
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