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
I have an odd problem that I'd like anyone's opinion on. I have a data stream, that I'd like to write into SDRAM (I'm writing my own controller, so I can do it any way I'd like). However, I don't want to write across a row (like you're supposed to do, so you can take advantage of bursting), but rather across a column. This means that every word would go to a different row. So, every word would require a full write cycle (active, write, precharge). This is far too slow. So, I got the idea of "bursting" across the banks (which allows for 4 writes, before a precharge), like this: (A=Active, W= write, P = precharge, r=row, b=bank, c=column) A (r 0, b 0), W (c 0, b 0), A (r 0, b 1), W (c 0, b 1), A (r 0, b 2), W (c 0, b 2), A (r 0, b 3), W (c 0, b 3), P then A (r 1, b 0), W (c 0, b 0), A (r 1, b 1), W (c 0, b 1), A (r 1, b 2), W (c 0, b 2), A (r 1, b 3), W (c 0, b 3), P and so on (with the required NOPs, to meet timing). I was also considering doing all the actives, then writes, then precharge (A, A, A, A, W, W, W, W, P). Any other suggestions?Article: 47326
Markus, We use LVDS with a spartan-2 to transmit data at 160 Mbps reliably over 100ft + (30m) of CAT-5 cable. I am using parts from National and TI for the LVDS, but I am ready to try the spartan2e's built-in LVDS. I use a 8b/10b encoding and have enough protocol to detect errors and resend packets. It works great. I believe that much higher speeds are possible (the parts are 400 Mbps), especially with shorter cables. I am running synchronous, with one pair as a clock and another pair as data, but you should be able to build a high-speed UART to receive this without a clock. Xilinx has some good app notes on this design. National also has some good app notes on LVDS over cat-5. Jason Daughenbaugh http://www.aedinc.net meng.engineering@bluewin.ch (Markus Meng) wrote in message news:<aaaee51b.0209230623.700eae42@posting.google.com>... > hi all, > > has anybody done this using spartan-ii with - for example - > an LVDS interface? > > What I require is a fast serial - bus like - connection between > 3 or 4 electronic modules. Those modules are close to each other > but in separate cabinets. I would like to use - let's say - RJ11 > connector and cabling, the speed should be ~ 100 Mbps > > markusArticle: 47327
"A. Nelson" wrote: > > I have an odd problem that I'd like anyone's opinion on. > > I have a data stream, that I'd like to write into SDRAM (I'm writing my own > controller, so I can do it any way I'd like). However, I don't want to > write across a row (like you're supposed to do, so you can take advantage of > bursting), but rather across a column. > > This means that every word would go to a different row. So, every word > would require a full write cycle (active, write, precharge). This is far > too slow. > > So, I got the idea of "bursting" across the banks (which allows for 4 > writes, before a precharge), like this: > > (A=Active, W= write, P = precharge, r=row, b=bank, c=column) > > A (r 0, b 0), W (c 0, b 0), A (r 0, b 1), W (c 0, b 1), A (r 0, b 2), W (c > 0, b 2), A (r 0, b 3), W (c 0, b 3), P > > then > > A (r 1, b 0), W (c 0, b 0), A (r 1, b 1), W (c 0, b 1), A (r 1, b 2), W (c > 0, b 2), A (r 1, b 3), W (c 0, b 3), P > > and so on (with the required NOPs, to meet timing). > > I was also considering doing all the actives, then writes, then precharge > (A, A, A, A, W, W, W, W, P). > > Any other suggestions? I think you have the right idea. By doing all the activates sequentially, you will minimize the number of noops. It has been awhile since I have done any work with SDRAMs, but I think you can do a precharge on one bank at a time. Not knowing how fast you are planning to clock the part, I can't say which way would be faster. I believe you would have to put noops before and after the single precharge. If you use four bank precharge commands you may not need noops at all. You will need to work out the details based on your clock speed and the parts you choose. Just curious about why you want to write across the columns. Does it have to do with how you are reading the data out? Are you using the SDRAM to permute the data? -- 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: 47328
since you are not bursting at all, you could use the auto precharge and save
yourself some steps in the controller. Also, if you can buffer up a few of the
writes, you can use short bursts on each row so that you can totally hide the
actives and precharges except where you switch between read and write.
I am assuming you are doing this because of the way you are reading the data back
out, otherwise switch the row and column and do things with normal bursts.
rickman wrote:
> "A. Nelson" wrote:
> >
> > I have an odd problem that I'd like anyone's opinion on.
> >
> > I have a data stream, that I'd like to write into SDRAM (I'm writing my own
> > controller, so I can do it any way I'd like). However, I don't want to
> > write across a row (like you're supposed to do, so you can take advantage of
> > bursting), but rather across a column.
> >
> > This means that every word would go to a different row. So, every word
> > would require a full write cycle (active, write, precharge). This is far
> > too slow.
> >
> > So, I got the idea of "bursting" across the banks (which allows for 4
> > writes, before a precharge), like this:
> >
> > (A=Active, W= write, P = precharge, r=row, b=bank, c=column)
> >
> > A (r 0, b 0), W (c 0, b 0), A (r 0, b 1), W (c 0, b 1), A (r 0, b 2), W (c
> > 0, b 2), A (r 0, b 3), W (c 0, b 3), P
> >
> > then
> >
> > A (r 1, b 0), W (c 0, b 0), A (r 1, b 1), W (c 0, b 1), A (r 1, b 2), W (c
> > 0, b 2), A (r 1, b 3), W (c 0, b 3), P
> >
> > and so on (with the required NOPs, to meet timing).
> >
> > I was also considering doing all the actives, then writes, then precharge
> > (A, A, A, A, W, W, W, W, P).
> >
> > Any other suggestions?
>
> I think you have the right idea. By doing all the activates
> sequentially, you will minimize the number of noops. It has been awhile
> since I have done any work with SDRAMs, but I think you can do a
> precharge on one bank at a time. Not knowing how fast you are planning
> to clock the part, I can't say which way would be faster.
>
> I believe you would have to put noops before and after the single
> precharge. If you use four bank precharge commands you may not need
> noops at all. You will need to work out the details based on your clock
> speed and the parts you choose.
>
> Just curious about why you want to write across the columns. Does it
> have to do with how you are reading the data out? Are you using the
> SDRAM to permute the data?
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design URL http://www.arius.com
> 4 King Ave 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 47329
This RPM pack error has been investigated and found to be a bug in the mappers
pack code. A fix is scheduled for 5.1i service Pack 3 which will become
available in December, 2002.
Regards,
Bret Wade
Xilinx Product Applications
Jan Gray wrote:
> Following up on my earlier article, "RAM32X1S, Virtex-II, 4.1i PAR travails"
> (
> http://groups.google.com/groups?selm=a5j91k%24akt%241%40slb3.atl.mindspring.
> net ), I am now trying to make a trivial RPM, consisting of a RAM32X1S and a
> DFF, RLOC'd to the same slice.
>
> No matter what I try (including adding BELs), no joy.
>
> I get a variant of:
>
> ERROR:Pack:679 - Unable to obey design constraints (MACRONAME=r/hset,
> RLOC=X0Y0)
> which require the combination of the following symbols into a single slice
> component:
> FLOP symbol "r/dff" (Output Signal = q)
> RAM symbol "r/ram/F" (Output Signal = r/ram/F)
> RAM symbol "r/ram/G" (Output Signal = r/ram/G)
> WEDECODE symbol "r/ram/WEDECODE" (Output Signal = r/ram/WEDECODE)
> BUF symbol "r/ram/BXBUF" (Output Signal = r/ram/A4')
> Unable to pack the register r/dff because of connectivity restrictions.
> Please correct the design constraints accordingly.
>
> I happen to know this is a perfectly legal packing of the slice, because if
> I DELETE the RLOC constraint on the DFF, the placer is quite happy to place
> the DFF in the same slice as the RAM32X1S on its own initiative.
> Specifically, the two 4-LUT RAM outputs go through the F5MUX, the F5 input
> of the FXMUX, and out onto output X, then back in on input DX, through the
> DXMUX and into the D input of FFX.
>
> This problem occurs in 4.1i, so I thought I'd try it under 4.2i. So I
> installed 4.2i. And 4.2i SP3. See following message for my blue screen of
> death travails there.
>
> Nope, not even 4.2i SP3 will accept my RAM32X1S and my DFF RLOC'd to the
> same slice.
>
> Can anyone offer any workarounds short of hard LOCs or XDL? I use RPMs to
> get repeatable datapath placements and timings so that I can tune up my
> design in a methodical way. Anything else is playing whack-a-mole on the
> critical paths.
>
> Quick and dirty Synplicity example:
>
> module tramq(clk, i, o);
> input clk, i;
> output o;
> reg o;
> reg we;
> reg [4:0] ad;
> reg d;
> ramq r(clk, we, ad, d, q);
> always @(posedge clk) begin
> {we, ad, d} <= {ad, d, i};
> o <= q;
> end
> endmodule
>
> module ramq(clk, we, ad, d, q)
> /* synthesis syn_hier="hard"*/;
> input clk, we, d;
> input [4:0] ad;
> output q;
> wire o;
> RAM32X1S ram(.A0(ad[0]), .A1(ad[1]), .A2(ad[2]), .A3(ad[3]), .A4(ad[4]),
> .D(d), .O(o), .WCLK(clk), .WE(we))
> /* synthesis RLOC="X0Y0" */;
> FD dff(.C(clk), .D(o), .Q(q))
> /* synthesis RLOC="X0Y0" */;
> endmodule
>
> Thanks.
> Jan Gray, Gray Research LLC
Article: 47330Read the report. It describes how we tested in parallel thousands (!) of devices for many months at 125 degrees C, in order to achieve any statistically meaningful failure rate. Then we (like everybody else) use the Arrhenius model to calculate MTBF at more reasonable temperatures. This kind of testing is not fast, and is not cheap. But it has to be done... Boring reading, but important facts. Peter Alfke ==================== Simon wrote: > Millions of hours ? A million hours is ~114 years... I thought there was > generally an "acceleration" involved in the calculation. If so, what are > the systematic error-bars on those estimates ? > > Actually, I don't really care :-) I was just a bit taken aback by the > apparent centuries of testing already performed by Xilinx <grin> >Article: 47331
Blackie Beard wrote: > > There ought to be a comp.arch.asic group. There > are some groups if you search on 'chip'. But I don't > know how relevant they are to you. > > "Reala" <-> wrote in message news:amdu7m$gar17@imsp212.netvigator.com... > > Hi, > > > > Sorry that I ask the question about IC layout, but I cannot find any > > newsgroup about IC layout. > > Sorry for any inconvinence. > > > > Anyone can tell me some homepage or newsgroup talk about IC layout? > > Thank you. > > > > Reala > > > > > > Hi, I think You could take a look at http://www.deepchip.com and subscribe John Cooley's ESNUG newsletter. IC layout is one of the many interesting subjects there. Regards, Veli-MattiArticle: 47332
But, how about the unused pins on Xilinx device? default to drive grand or be left floating? SpartanII and Virtex device. -- DarylArticle: 47333
Hello,
I,m new to CPLD/FPGA and have few questions?
#How to transfer a VHDL code on cpld/fpga?
#How much a single cpld cost?
#Is it really economical to use cpld/fpga for a dedicated purpose
equipment
with limited scope?e.g. a harness tester,a handheld banking system
machine,billing machine on any counter etc.
If it is really not economical,is there any other alternative to
develop/design chips for such limited scope machines(where mass
production may not be possible).
Thanking in advance.
rahul
Article: 47334
Bret Wade <bret.wade@xilinx.com> wrote in message news:<3D8FB6EC.A33F615F@xilinx.com>...
> This RPM pack error has been investigated and found to be a bug in the mappers
> pack code. A fix is scheduled for 5.1i service Pack 3 which will become
> available in December, 2002.
>
> Regards,
> Bret Wade
> Xilinx Product Applications
>
> Jan Gray wrote:
>
> > Following up on my earlier article, "RAM32X1S, Virtex-II, 4.1i PAR travails"
> > (
> > http://groups.google.com/groups?selm=a5j91k%24akt%241%40slb3.atl.mindspring.
> > net ), I am now trying to make a trivial RPM, consisting of a RAM32X1S and a
> > DFF, RLOC'd to the same slice.
> >
> > No matter what I try (including adding BELs), no joy.
> >
> > I get a variant of:
> >
> > ERROR:Pack:679 - Unable to obey design constraints (MACRONAME=r/hset,
> > RLOC=X0Y0)
> > which require the combination of the following symbols into a single slice
> > component:
> > FLOP symbol "r/dff" (Output Signal = q)
> > RAM symbol "r/ram/F" (Output Signal = r/ram/F)
> > RAM symbol "r/ram/G" (Output Signal = r/ram/G)
> > WEDECODE symbol "r/ram/WEDECODE" (Output Signal = r/ram/WEDECODE)
> > BUF symbol "r/ram/BXBUF" (Output Signal = r/ram/A4')
> > Unable to pack the register r/dff because of connectivity restrictions.
> > Please correct the design constraints accordingly.
> >
> > I happen to know this is a perfectly legal packing of the slice, because if
> > I DELETE the RLOC constraint on the DFF, the placer is quite happy to place
> > the DFF in the same slice as the RAM32X1S on its own initiative.
> > Specifically, the two 4-LUT RAM outputs go through the F5MUX, the F5 input
> > of the FXMUX, and out onto output X, then back in on input DX, through the
> > DXMUX and into the D input of FFX.
> >
> > This problem occurs in 4.1i, so I thought I'd try it under 4.2i. So I
> > installed 4.2i. And 4.2i SP3. See following message for my blue screen of
> > death travails there.
> >
> > Nope, not even 4.2i SP3 will accept my RAM32X1S and my DFF RLOC'd to the
> > same slice.
> >
> > Can anyone offer any workarounds short of hard LOCs or XDL? I use RPMs to
> > get repeatable datapath placements and timings so that I can tune up my
> > design in a methodical way. Anything else is playing whack-a-mole on the
> > critical paths.
> >
> > Quick and dirty Synplicity example:
> >
> > module tramq(clk, i, o);
> > input clk, i;
> > output o;
> > reg o;
> > reg we;
> > reg [4:0] ad;
> > reg d;
> > ramq r(clk, we, ad, d, q);
> > always @(posedge clk) begin
> > {we, ad, d} <= {ad, d, i};
> > o <= q;
> > end
> > endmodule
> >
> > module ramq(clk, we, ad, d, q)
> > /* synthesis syn_hier="hard"*/;
> > input clk, we, d;
> > input [4:0] ad;
> > output q;
> > wire o;
> > RAM32X1S ram(.A0(ad[0]), .A1(ad[1]), .A2(ad[2]), .A3(ad[3]), .A4(ad[4]),
> > .D(d), .O(o), .WCLK(clk), .WE(we))
> > /* synthesis RLOC="X0Y0" */;
> > FD dff(.C(clk), .D(o), .Q(q))
> > /* synthesis RLOC="X0Y0" */;
> > endmodule
> >
> > Thanks.
> > Jan Gray, Gray Research LLC
Hi all,
I have a doubt. if we give the RLOC = "X0Y0", it will be passed to the
xilinx's PAR tool through the edif file. is that right?
Is this a Permenet location of the FF or module whatever may be? or
the PAR tool can move the module or FF location if timing is not
acheived.
How it will become, Relative Positional Macro.?
Best regards,
Muthu
Article: 47335Stephen Williams <db6jn001@sneakemail.com> writes: > If you want a stable work environment, start getting used to the > idea of moving to Linux. I just can't see *why* Xilinx doesn't provide a native Linux version of their tools? I would expect it would be as easy to port the Solaris version to native Linux as it would be to use Wine and the Windows version. You would then get the multinode place and route (PAR) feature found in the Solaris version. I have access to large clusters of Linux based PC where I wish I could run multiple iterations of PAR jobs in parallel. Also some of the new Virtex II Pro PowerPC processor model and Gigabit serial interface models are provided as SWIFT models. This means that you need access to a simulator like Synopsys VCS or Cadence Verilog (I don't know if Modeltech supports SWIFT under Windows?). I can imagine running PAR and simulation jobs on the large Virtex II Pro devices and future device families will require a large amount of RAM. Running on a 64-bit X86 (http://www.x86-64.org) would result in a high performance low cost solution. Petter BTW. Steve: Thank you for providing Icarus Verilog. -- ________________________________________________________________________ Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petterArticle: 47336
On 24 Sep 2002 00:59:40 -0700, muthu_nano@yahoo.co.in (Muthu) wrote:
>Bret Wade <bret.wade@xilinx.com> wrote in message news:<3D8FB6EC.A33F615F@xilinx.com>...
>> This RPM pack error has been investigated and found to be a bug in the mappers
>> pack code. A fix is scheduled for 5.1i service Pack 3 which will become
>> available in December, 2002.
>>
>> Regards,
>> Bret Wade
>> Xilinx Product Applications
>>
>> Jan Gray wrote:
>>
>> > Following up on my earlier article, "RAM32X1S, Virtex-II, 4.1i PAR travails"
>> > (
>> > http://groups.google.com/groups?selm=a5j91k%24akt%241%40slb3.atl.mindspring.
>> > net ), I am now trying to make a trivial RPM, consisting of a RAM32X1S and a
>> > DFF, RLOC'd to the same slice.
>> >
>> > No matter what I try (including adding BELs), no joy.
>> >
>> > I get a variant of:
>> >
>> > ERROR:Pack:679 - Unable to obey design constraints (MACRONAME=r/hset,
>> > RLOC=X0Y0)
>> > which require the combination of the following symbols into a single slice
>> > component:
>> > FLOP symbol "r/dff" (Output Signal = q)
>> > RAM symbol "r/ram/F" (Output Signal = r/ram/F)
>> > RAM symbol "r/ram/G" (Output Signal = r/ram/G)
>> > WEDECODE symbol "r/ram/WEDECODE" (Output Signal = r/ram/WEDECODE)
>> > BUF symbol "r/ram/BXBUF" (Output Signal = r/ram/A4')
>> > Unable to pack the register r/dff because of connectivity restrictions.
>> > Please correct the design constraints accordingly.
>> >
>> > I happen to know this is a perfectly legal packing of the slice, because if
>> > I DELETE the RLOC constraint on the DFF, the placer is quite happy to place
>> > the DFF in the same slice as the RAM32X1S on its own initiative.
>> > Specifically, the two 4-LUT RAM outputs go through the F5MUX, the F5 input
>> > of the FXMUX, and out onto output X, then back in on input DX, through the
>> > DXMUX and into the D input of FFX.
>> >
>> > This problem occurs in 4.1i, so I thought I'd try it under 4.2i. So I
>> > installed 4.2i. And 4.2i SP3. See following message for my blue screen of
>> > death travails there.
>> >
>> > Nope, not even 4.2i SP3 will accept my RAM32X1S and my DFF RLOC'd to the
>> > same slice.
>> >
>> > Can anyone offer any workarounds short of hard LOCs or XDL? I use RPMs to
>> > get repeatable datapath placements and timings so that I can tune up my
>> > design in a methodical way. Anything else is playing whack-a-mole on the
>> > critical paths.
>> >
>> > Quick and dirty Synplicity example:
>> >
>> > module tramq(clk, i, o);
>> > input clk, i;
>> > output o;
>> > reg o;
>> > reg we;
>> > reg [4:0] ad;
>> > reg d;
>> > ramq r(clk, we, ad, d, q);
>> > always @(posedge clk) begin
>> > {we, ad, d} <= {ad, d, i};
>> > o <= q;
>> > end
>> > endmodule
>> >
>> > module ramq(clk, we, ad, d, q)
>> > /* synthesis syn_hier="hard"*/;
>> > input clk, we, d;
>> > input [4:0] ad;
>> > output q;
>> > wire o;
>> > RAM32X1S ram(.A0(ad[0]), .A1(ad[1]), .A2(ad[2]), .A3(ad[3]), .A4(ad[4]),
>> > .D(d), .O(o), .WCLK(clk), .WE(we))
>> > /* synthesis RLOC="X0Y0" */;
>> > FD dff(.C(clk), .D(o), .Q(q))
>> > /* synthesis RLOC="X0Y0" */;
>> > endmodule
>> >
>> > Thanks.
>> > Jan Gray, Gray Research LLC
>
>Hi all,
>
>I have a doubt. if we give the RLOC = "X0Y0", it will be passed to the
>xilinx's PAR tool through the edif file. is that right?
Yes, that is right.
>Is this a Permenet location of the FF or module whatever may be? or
>the PAR tool can move the module or FF location if timing is not
>acheived.
>
>How it will become, Relative Positional Macro.?
RLOC = *relative* location. This ff is located with respect to other
flip flops in this module. The entire module may be located (relative
or absolute) in the higher level module that instantiates this one, or
if not, the placer can put it anywhere, but the relative locations
*within this module* remain the same.
LOC = *absolute* location. This ff is located at a fixed location on
the die.
Regards,
Allan.
Article: 47337rahul joshi wrote: > > Hello, > > I,m new to CPLD/FPGA and have few questions? > #How to transfer a VHDL code on cpld/fpga? You need to compile the HDL source, and place/route/fit the intermediate file ( typ EDIF or PLA ), to create the a binary device file. This is then loaded into the target device, either serially, or using a device programmer. So, flow wise, it's very similar to HLL -> ASM -> HEX -> uC > #How much a single cpld cost? Typical med volume price curve is ~ $1/32Mcells > #Is it really economical to use cpld/fpga for a dedicated purpose > equipment > with limited scope?e.g. a harness tester,a handheld banking system > machine,billing machine on any counter etc. > If it is really not economical,is there any other alternative to > develop/design chips for such limited scope machines(where mass > production may not be possible). CPLD/FPGA are well suited to those tasks beyond typical embedded controllers - so for harness testing, a uC could do this, but a CPLD will do it much faster. Same applies to Serial IO, RAM data pumps, state engines.... -jgArticle: 47338
On Mon, 23 Sep 2002 18:24:54 -0400, "A. Nelson" <anelson@NS.lumenera.com> wrote: >I have an odd problem that I'd like anyone's opinion on. > >I have a data stream, that I'd like to write into SDRAM (I'm writing my own >controller, so I can do it any way I'd like). However, I don't want to >write across a row (like you're supposed to do, so you can take advantage of >bursting), but rather across a column. > >This means that every word would go to a different row. So, every word >would require a full write cycle (active, write, precharge). This is far >too slow. > >So, I got the idea of "bursting" across the banks (which allows for 4 >writes, before a precharge), like this: > >(A=Active, W= write, P = precharge, r=row, b=bank, c=column) > >A (r 0, b 0), W (c 0, b 0), A (r 0, b 1), W (c 0, b 1), A (r 0, b 2), W (c >0, b 2), A (r 0, b 3), W (c 0, b 3), P > >then > >A (r 1, b 0), W (c 0, b 0), A (r 1, b 1), W (c 0, b 1), A (r 1, b 2), W (c >0, b 2), A (r 1, b 3), W (c 0, b 3), P > >and so on (with the required NOPs, to meet timing). > >I was also considering doing all the actives, then writes, then precharge >(A, A, A, A, W, W, W, W, P). > >Any other suggestions? You could use a small SRAM (e.g. xilinx block ram) as a reorder buffer. Collect N rows worth of columns in the SRAM then do bursts of length N into the SDRAM. Even N as small as 2 would give you a significant speedup. Regards, Allan.Article: 47339
writes: [Stephen Williams] > > If you want a stable work environment, start getting used to the > > idea of moving to Linux. [Rick "rickman" Collins] > That sounds like a great concept, but in the real world, Linux is hardly > supported. Xilinx only supports it running with WINE IIRC and they have I guess it depends upon your world :-) I've been using Chronologic VCS (now Synopsys), Design Acceleration Signalscan (now Cadence), Cadence Verilog, Finsim, Synopsys Design Compiler etc. for many years under Linux. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petterArticle: 47340
Hello, Looking to the market we see an upcoming trend in programmable analogue fpga based devices. At this moment i'm researching these devices. Devices like the FPAA - Anadigm, Trac - Zetex, ispPAC - Lattice, PSoC - Cypress and the FIPSOC - SIDSA are good examples of these. I wanna know if anyone knows something more about other devices fitting in this category? And maybe there is someone who got more experience with applications where these devices are used. Tell me please more about that i'm very interested in it. And does anyone knows something more about the FIPSOC? It seems a very unknow device to me... Thanx Dennis Sneijers, Oce Technologies BV Venlo, NetherlandArticle: 47341
Dennis Sneijers wrote: > > Hello, > > Looking to the market we see an upcoming trend in programmable analogue > fpga based devices. At this moment i'm researching these devices. > Devices like the FPAA - Anadigm, Trac - Zetex, ispPAC - Lattice, PSoC - > Cypress and the FIPSOC - SIDSA are good examples of these. > > I wanna know if anyone knows something more about other devices fitting > in this category? And maybe there is someone who got more experience > with applications where these devices are used. Tell me please more > about that i'm very interested in it. And does anyone knows something > more about the FIPSOC? It seems a very unknow device to me... We put a link to this on our web site, but the PDF for FIPSOC1 is dated June 99, and nothing more recent shows in the press info, so I would say it is 'paused' :) On "Analog FPGA" generally, their biggest drawback is the very poor and narrow-use analog performance - besides being single-sourced in the worst sense, they cannot compete with the leading edge analog companies, which are leaving them behind in specs. Dynamic range, distortion and noise are commonly so mediocre, they are left off the 'Overview' promo materials entirely (eg ispPAC) They look nice to play with, and look good in press releases, but do you know anyone who has actually used one in a real product ? -jgArticle: 47342
: P.S. Which books (either online and not) do you suggest as a : beginner/intermediate VHDL reference focused on programmable logic : syntesis? I am reading some generic VHDL books like the "VHDL Cookbook", : but they are very abstract and obsolete. : -- : Lorenzo Hi Lorenzo, I have also been learning (to tolerate ;-) VHDL recently. I've got "Introductory VHDL, From Simulation to Synthesis" by Sudhakar Yalamanchili. It's aimed at the old Foundation bassed Xilinx stuff, not the new ISE series, but most of the book can be taken as standallone VHDL for PLDs. I found the book worked very well when taken in conjunction with all the VHDL code I could lay my hands on, and using the book to understand how the code works. Having spent a lot of time with the foundation simulator craating waveforms in the past, the chapter on creating VHDL testbenches was particularly invaliable! some grumbles (common to a lot of VHDL books I've looked at): 1) Why are code snippets printed in a proportional font? 2) Indentation. I know VHDL does not have any inbuilt indentation standards, but I am a firm believer than sensibly used indentation makes readability, and therefore the ease of spotting / preventing errors soars. The indentation in the code snippets is pretty arbitrary. If you are starting out with Modlesim, I can highly recomend the following text (or there abouts) I saw somewhere, then forgot about, then remembered after half an hour of wondering why a simulation was going wrong... "Simulators and Synthesis tools attatch different importances to a process' sensitivy list. An incomplete sensitivy list will probably not affect the results of synthesis, but will cause a simulator limit the conditions under which the process is executed beyond those you wish." Modelsim doesn't seem to raise an eyebrow to an incomplete sensitivity list (after all, as far as modelsim is concerned, the code might never be destined for a PLD, so perhaps you meant it that way) - however XST raises warnings when synthesising such code. I can highly recomend 1) Writing your VHDL, whilst remembering to check for the above 2) Synthesising the VHDL, or running it through a validator (anyone got any good pointers for such things?) 3) grepping the synthesiser logs for the word 'incomplete' 4) Checking and fixing the VHDL 4) Repearing 2-4 till you are satisfied 5) Simulating. After a while doing it the right way becomes second nature. --- cheers cdsArticle: 47343
I have a problem with a design ( 200k spartan II E ) that fail when an Electrostatic discharge occurs. I presume that some flip-flop are reseted but not all. That means that my design fail and is unstable. I have set some hardware things to avoid a large part of this problems but when it occurs I always fail. Have you got any Idea to secure the FPGA design itself ? Regards. Jérémie WEBERArticle: 47344
IIRC, the Altera-Xilinx deal that allowed cross-patents means Altera can use the term FPGA instead of CPLD. -Xanatos "Leon Heller" <leon_heller@hotmail.com> wrote in message news:amnbbe$abf$1@paris.btinternet.com... > I see that Altera is referring to the new Cyclone devices as 'FPGAs'. I > don't recall them using the term FPGA, before. Is this a new marketing ploy? > > Leon > -- > Leon Heller, G1HSM > leon_heller@hotmail.com > http://www.geocities.com/leon_heller > >Article: 47345
Hi guys,
I tried to post the other day via Google but it failed.
Take a look at the application note that I wrote about loops in Handel-C at
http://www.celoxica.com/products/technical_papers/application_notes/71%20-%2
0Optimisation%20-%20Efficient%20Loops.pdf.
This gives a good explanation of how to write decent loops.
While loops are the way to go as they are more versatile and easier to
understand IMHO.
Cheers
Ashley
"Govind Kharbanda" <govind.kharbanda@sli-institute.ac.uk> wrote in message
news:2f5db38d.0209180701.777672ae@posting.google.com...
> "Alan Fitch" <alan.fitch@doulos.com> wrote in message
news:<k0pFl7kWCHA.4780@lucy.doulos.com>...
> > Firstly, you might want to try this option.
> >
> > A for loop
> >
> > for (i = 0; i<10; i++)
> > {
> > statements;
> > }
> >
> > can be replaced with
> >
> > for (i = 0; i < 10) par {
> > i++;
> > statements;
> > }
> >
> > which speeds up the execution of a for loop.
>
> That's something I didn't know... I was always recoding as a 'while'
> loop. Your solution is much easier to follow.
>
> > Secondly, if you use the value of i inside a nested loop, you need
> > to be very
> > careful to make sure that if you use the outer loop variable in an
> > inner loop,
> > you are using the correct value (because in Handel-C the variables
> > may update
> > in parallel rather than sequentially as in C).
> >
> > <snip complicated code>
> >
>
> I solved this by recoding the loop so a shift is performed on each
> iteration instead of an increment.
>
> I am getting a new problem though concerning calling a macro procedure
> within this complicated loop: see new thread.
>
> > > Also the compiler is throwing up width errors, for instance
> > width '8'
> > > doesn't match width '4'. For instance
> > >
> > > while (j<(1<<i))
> > >
>
> I solved this by recoding the loop so a shift is performed on each
> iteration instead of an increment.
>
> > However the value '1' is not known. Try using
> >
> > while (j < (unsigned 8)(1 << i))
> >
> > or declaring a constant to represent the number 1 of the correct
> > width, e.g.
> >
> > static const unsigned 8 ONE = 1;
> >
> > and then using
> >
> > ONE << i
> >
>
> I like this idea though - will try and make use of it.
>
> Govind
Article: 47346"rickman" <spamgoeshere4@yahoo.com> wrote in message news:3D8F9E76.79972BE5@yahoo.com... > "A. Nelson" wrote: > > > > I have an odd problem that I'd like anyone's opinion on. > > > > I have a data stream, that I'd like to write into SDRAM (I'm writing my own > > controller, so I can do it any way I'd like). However, I don't want to > > write across a row (like you're supposed to do, so you can take advantage of > > bursting), but rather across a column. > > > > This means that every word would go to a different row. So, every word > > would require a full write cycle (active, write, precharge). This is far > > too slow. > > > > So, I got the idea of "bursting" across the banks (which allows for 4 > > writes, before a precharge), like this: > > > > (A=Active, W= write, P = precharge, r=row, b=bank, c=column) > > > > A (r 0, b 0), W (c 0, b 0), A (r 0, b 1), W (c 0, b 1), A (r 0, b 2), W (c > > 0, b 2), A (r 0, b 3), W (c 0, b 3), P > > > > then > > > > A (r 1, b 0), W (c 0, b 0), A (r 1, b 1), W (c 0, b 1), A (r 1, b 2), W (c > > 0, b 2), A (r 1, b 3), W (c 0, b 3), P > > > > and so on (with the required NOPs, to meet timing). > > > > I was also considering doing all the actives, then writes, then precharge > > (A, A, A, A, W, W, W, W, P). > > > > Any other suggestions? > > I think you have the right idea. By doing all the activates > sequentially, you will minimize the number of noops. It has been awhile > since I have done any work with SDRAMs, but I think you can do a > precharge on one bank at a time. Not knowing how fast you are planning > to clock the part, I can't say which way would be faster. > > I believe you would have to put noops before and after the single > precharge. If you use four bank precharge commands you may not need > noops at all. You will need to work out the details based on your clock > speed and the parts you choose. > > Just curious about why you want to write across the columns. Does it > have to do with how you are reading the data out? Are you using the > SDRAM to permute the data? > Why am I writing across the columns? I'm trying to rotate a rather large image, 90 degrees. This way, when the data is read out of the RAM, it can be read out "normally", and will be rotated. Because the image is large, I really don't have the space to buffer even a couple of lines (I could probalby buffer one, but I really don't want to). Just one more question about SDRAMs: Trcd is listed as the minimum time between Active and Read/Write. Now, is this between ANY Active and Write, or between Active for a specific row/bank and a write to that same row/bank? For example, if I do the 4 consecutive Acitves (which would be for banks 0 to 3 consectutively), followed by 4 writes (again, for banks 0 to 3 consectutively), do I have to wait Trcd between the LAST Active and the FIRST Write, or Trcd between the FIRST Active and FIRST Write? Thanks for everyone's input, A. > -- > > 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: 47347
Hi All, I am struggling to define some timing constraints for a latch based design. In my design i have a number of latches that i want to mark as "feed thru" i.e. Xilinx will not use them as an endpoint for timing analysis. E.g Latch1 -> Latch2 -> Latch3 By default Xilinx timing analysis all treat all 3 Latches as end points. In my design i want to mark Latch2 as pass-thru so that i can apply a constraint from Latch1 THRU Latch2 TO Latch3. I have tried/observed the following. 1. the ucf supports the following path tracing constraint for Latches ENABLE = lat_d_q; This makes ALL latches in the design as pass thru. Not what i want. 2. the COnstraints guide, hints that this ENABLE can be applied to a timegroup. However it only gives an example for the PCF file TIMEGRP "name" ENABLE = lat_d_q; I tried this by changing the PCF, and running the trce engine. It complained that the timegroup did not contain any "components" 3. Xilinx supports a FROM THRU TO constraint. However the THRU points can only be nets or TBUFs. 4. In the Timing Analyzer, when you do a timing analysis, you can specify individual Latches as been pass thru. Therefore it should be possible to apply these Path Tracing constraints in the UCF. HAs anyone come across this or have any suggestions? PS. I cannot analyse Latch1 to Latch2 and Latch2 to Latch3 seperatly. Thanks DerekArticle: 47348
Are the GCLK pins fixed to IBUFG's or can they be directed to IBUF's if GCLK pins are required for inputs instead of clocks?Article: 47349
I was trying a latch-based approach recently but luckily found a different way to use standard registered logic so I didn't have to rely on this troublesome technique. First, I thought the lat_d_q was a PCF only constraint. If it's now available for use in the UCF then you don't have to partially compile, edit the generated PCF, and finish the job. I would've loved that. WIth the lat_d_q in place, you have the ability to do FROM / TO analysis based on groups of latches. You can specify TIMEGRP TG_LatchesLo = TRASLO LATCHES; TIMEGRP TG_LatchesHi = TRASHI LATCHES; TIMESPEC TS_LoHi = FROM TG_LatchesLo TO TG_LatchesHi 5 ns; TIMESPEC TS_HiLo = FROM TG_LatchesHi TO TG_LatchesLo 5 ns; TIMESPEC TS_LoLo = FROM TG_LatchesLo TO TG_LatchesLo 10 ns; I used these before and had good success. You could specify "LATCHES( Latch1 Latch3 )" instead of just "LATCHES" or in place of the transition selection. You should find more on those constraints in the online Constraints Guide. Good luck. Latches are great but they're not fun. Derek Wallace wrote: > Hi All, > I am struggling to define some timing constraints for > a latch based design. > > In my design i have a number of latches that i want to mark as "feed thru" > i.e. Xilinx will not use them as an endpoint for timing analysis. > > E.g Latch1 -> Latch2 -> Latch3 > By default Xilinx timing analysis all treat all 3 Latches as end points. > In my design i want to mark Latch2 as pass-thru so that i can > apply a constraint from Latch1 THRU Latch2 TO Latch3. > > I have tried/observed the following. > 1. the ucf supports the following path tracing constraint for Latches > ENABLE = lat_d_q; > > This makes ALL latches in the design as pass thru. Not what i want. > > 2. the COnstraints guide, hints that this ENABLE can be applied to a timegroup. > However it only gives an example for the PCF file > TIMEGRP "name" ENABLE = lat_d_q; > > I tried this by changing the PCF, and running the trce engine. It complained > that the timegroup did not contain any "components" > > 3. Xilinx supports a FROM THRU TO constraint. > However the THRU points can only be nets or TBUFs. > > 4. In the Timing Analyzer, when you do a timing analysis, > you can specify individual Latches as been pass thru. > > Therefore it should be possible to apply these Path Tracing constraints > in the UCF. > > HAs anyone come across this or have any suggestions? > > PS. I cannot analyse Latch1 to Latch2 and Latch2 to Latch3 seperatly. > > Thanks > Derek
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