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
Thomas Heller <theller@ctypes.org> writes: > I know this is a question which is difficult to be answered, > but does anyone have an estimate which Spartan-6 fpga has > comparable 'size' as a xc2v1000 or a xc2v3000 fpga? > With 'size' I don't mean chip dimensions, I mean logic > functionality. > xc2v1000 has about 5000 slices, so about 10k (4-input) luts and flipflops. It also has 40 blockrams and 40 multipliers. It depends if you are LUT or flipflop limited (or memory/multiplier). Note that Spartan-6 LUTs are 6-input and there re 2 flops per LUT. A Spartan 6 LX16 has about 9k LUTs (hence 18k flipflops). The next one down might suit (LX9) - ~5700 LUTs, >10k flipflops. Both have 32 BRAMs, 16 DSP blocks (multiplier + extras) in the LX9, 32 in the LX16. You can do the comparisons from here: http://www.xilinx.com/support/documentation/data_sheets/ds031.pdf http://www.xilinx.com/support/documentation/data_sheets/ds160.pdf > A very rough estimate would be enough... > Given the change in CLB architecture, that's all it'll ever be unless you port your code across... Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 153751
Am 10.05.2012 11:32, schrieb Martin Thompson: > Thomas Heller<theller@ctypes.org> writes: > >> I know this is a question which is difficult to be answered, >> but does anyone have an estimate which Spartan-6 fpga has >> comparable 'size' as a xc2v1000 or a xc2v3000 fpga? >> With 'size' I don't mean chip dimensions, I mean logic >> functionality. >> > > xc2v1000 has about 5000 slices, so about 10k (4-input) luts and > flipflops. It also has 40 blockrams and 40 multipliers. > > It depends if you are LUT or flipflop limited (or memory/multiplier). > Note that Spartan-6 LUTs are 6-input and there re 2 flops per LUT. > > A Spartan 6 LX16 has about 9k LUTs (hence 18k flipflops). The next > one down might suit (LX9) - ~5700 LUTs,>10k flipflops. > > Both have 32 BRAMs, 16 DSP blocks (multiplier + extras) in the LX9, 32 > in the LX16. > > You can do the comparisons from here: > > http://www.xilinx.com/support/documentation/data_sheets/ds031.pdf > http://www.xilinx.com/support/documentation/data_sheets/ds160.pdf > >> A very rough estimate would be enough... >> > > Given the change in CLB architecture, that's all it'll ever be unless you > port your code across... Well, this confirms the metrics that I used myself somewhat. Does the virtex 2 or the spartan 6 have a higher operating frequency, in practice? Thanks, ThomasArticle: 153752
While discombobulating a sporadically, hideously dysfunctional fsm today, it occurred to me that I know exactly what that circuit feels. If it has a sense of purpose, that is, and cares about the outcome. Now, a state machine sleeps most of its life, waking only briefly, regularly, to check its context, do its simple task, update the context, and then goes back to sleep. We don't think much about this; that's just what a FSM does. Except when the bookmark gets shredded and displaced. It occurred to me that I've felt this, personally, and it wasn't pleasant. Without boring you with the (illegal in this country) details, my clk got jumbled while vacationing in a resort in the Caribbean, on that big island just south of that other big one. Yeah, that one, the one that sings songs about ... I became aware of this, being lost in time, not through any direct sensation or measure. The whole point is that I was then completely unable to sense or measure time. It came to me as an overwhelming nausea of spatial disorientation. I was lost, in other words, while walking the short, mostly straight walkway from the hot tub to my rented room. The sensation was that I had been putting one foot in front of the other for at least half of forever -- there's the temporal displacement -- and surely, I must be there by now. (I had in reality walked about 20 yards.) In the early tropical night and in the strange to me surroundings, I was hopelessly lost and unable to reorient myself through other means. And so I've wondered over the years since, just how we measure time and navigate from place to place. Watching the sleeping jugheads around me drive the interstates, for example, I'm certain they've dialled down their clks, and are no longer completely aware of where they are. So, there it is. The inescapable conclusion is that neurons are biological FFs and LUTs. We operate on a clk -- unmeasurable internally, since it also happens to drive the measurement devices -- driving the simple FSMs we built to keep our place in the four dimensions. We lose our place in three -- gravity takes care of the fourth -- when the bufg gets whacked. I'm thinking right now, at the least, that perhpas I shouldn't have been so eager to poo-poo the poor guy and his FPGA everywhere idea recently. We *are* the ultimate culmination of FPGAs.Article: 153753
On Friday, 11 May 2012 09:49:05 UTC+1, Dr. Beau Webber wrote: > If you have an interest in exchanging data between circuitry in an FPGA a= nd a PC, I have written a simple GUI that demonstrates transfers at full US= B2 rates to and from an FPGA interfaced with an FTDI FT2232H USB2 interface= chip (i.e. the FTDI Morph-IC-II). >=20 > There is a free (binary only) download :=20 > http://www.lab-tools.com/instrumentation/download/FPGA_PC_Release_TF.z= ip , > or source code is available for both personal and commercial uses : i.e. > (Altera Quartus II v11.1sp2 archive) plus script source plus GUI binary = or source. I have slightly updated the code to Version 0.95 - it should now have some = slight functionality even if you do not have a Morph-IC-II FPGA module plug= ged in.=20 Note you will first need to download and install the APLX Support Library f= rom MicroApl : http://www.microapl.co.uk/apl/player/index.html . If you run= Norton, it will probably complain that the .exe file is infected - the fil= e is not infected, but it is a powerful piece of code, as it has to access = a number of .dlls to program and interface to the FPGA.Article: 153754
I agree Andy - making this into a function makes the code cleaner and is preferred if I would use this more than once.Article: 153755
Thomas Heller wrote: > Am 10.05.2012 11:32, schrieb Martin Thompson: [snip] > > Well, this confirms the metrics that I used myself somewhat. > Does the virtex 2 or the spartan 6 have a higher operating frequency, > in practice? > > Thanks, > Thomas In my experience, Spartan 6 runs faster than Virtex 2. In addition, you can reduce the number of logic levels because of larger LUTs. Spartan 6 also has many features that weren't introduced before Virtex 4, like DSP48's, SERDES on general I/O, variable IO delays, PLL's... Although the Spartan 6 fabric is not a whole lot faster than V2, the hard memory controllers allow you to use faster external memory, which can reduce pin count and power over using wider slower memory. DDR2 can easily do 312 MHz (400 MHz with tweaked VCCint). Also S6 uses much less power than V2. As noted, S6 doesn't have as much block RAM for the same fabric size, however the much lower price and lower power make it a win even if you need to use a larger S6 part to get the memory you need. -- GaborArticle: 153756
On May 13, 1:40=A0pm, Carl <carw...@gmail.com> wrote: > I agree Andy - making this into a function makes the code cleaner and > is preferred if I would use this more than once. Carl, I would encourage you and others to think about what "use this code more than once" means... Anyone reviewing the code? Anyone maintaining the code? In this context, "anyone" can be even be you, 6 weeks, 6 months or 6 years after you wrote it. For myself, I could include "6 days" too! Clean code is easier to understand for everyone. Good comments help, but well written code, with appropriately named entities, functions, procedures, variables, and signals, helps a lot more. For example byte_vector may be too general a name in some cases. Is the byte vector organized as little endian or big endian? Are both kinds used in the same environment? perhaps big_endian and/or little_endian are better names for the type. The to_unsigned() function could be overridden for each type appropriately. And naturally, to_big_endian(), etc. written as well. Something to think about... OK, I'm stepping off my soapbox now... AndyArticle: 153757
What's the big deal about a latch? Is it less efficient in floorspace than
an FDE? Or is it just some amount of combinatorial concerns? For example:
tsc_start <= tsc when sof_in_n = '0' and rising_edge(clk);
versus
tsc_start <= tsc when sof_in_n = '0';
What concerns are there with crossing clock domains with either? For
example, a 10 ns tick clock would be more directly meaningful than, say, a
125 MHz clock in this application. (The logic reading the value runs on a
different clock than the logic updating the value.)
Also, I had apparently missed the explanation of the semantic difference
between 'to' and 'downto'. Does simple intuition apply here, that with 'to',
low indexes reference the more significant bits or words?
Last, does the following infer a multiplier and adder in synthesis? I
wouldn't expect to see one, and didn't see one in the synthesis log or RTL
schematic, but the whole thing got really messy with simply adding the very
wide registers.
function w_tsc(val : std_logic_vector; i : natural) return
std_logic_vector is
variable lo : natural := i * 8;
variable hi : natural := lo + 7;
begin
return val(hi downto lo);
end function;
begin -- arch
with tx_state select
dout <= ....
w_tsc(tsc_start, 7) when SEND_TSC_START,
w_tsc(tsc_start, 6) when SEND_TSC_START_1,
w_tsc(tsc_start, 5) when SEND_TSC_START_2,
w_tsc(tsc_start, 4) when SEND_TSC_START_3,
w_tsc(tsc_start, 3) when SEND_TSC_START_4,
w_tsc(tsc_start, 2) when SEND_TSC_START_5,
...
Truly and finally last, is there a good way to generate the above, in the
midst of a selected assignment having other, unrelated states?
Thanks.
Article: 153758
I have this code written in verilog for a counter but my program xilinx ise
14.1 finds 2 errors:
ERROR:Xst:899 - "numarator9.v" line 45: The logic for <counter_out> does
not match a known FF or Latch template. The description style you are using
to describe a register or latch is not supported in the current software
release.
ERROR:Xst:899 - "numarator9.v" line 44: The logic for <carry_out> does not
match a known FF or Latch template. The description style you are using to
describe a register or latch is not supported in the current software
release.
Can someone help me and tell me what's wrong about my code?
module counter9 (
clock ,
reset ,
enable ,
counter_out,
carry_out,
preset
);
input clock ;
input reset ;
input enable ;
input [3:0] preset;
output [3:0] counter_out ;
output carry_out;
wire clock ;
wire reset ;
wire enable ;
wire [3:0] preset;
reg [3:0] counter_out ;
reg carry_out;
reg a;
always @ (posedge clock or negedge reset)
begin : COUNTER
if (enable == 1'b1) begin
a<=1'b1;
end
else begin a<=1'b0;
end
if (reset == 1'b0) begin
counter_out <= preset;
carry_out<= 1'b0;
a<=1'b0;
end
else if (a == 1'b1) begin
counter_out <= counter_out - 1;
end
if(counter_out==4'b0)begin
carry_out<=~carry_out;
counter_out<= counter_out + 9;
end
else begin
carry_out<=1'b0;
end
end
endmodule
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 153759
Legalex <andreiopariuc@n_o_s_p_a_m.gmail.com> wrote:
> I have this code written in verilog for a counter but my
> program xilinx ise 14.1 finds 2 errors:
> ERROR:Xst:899 - "numarator9.v" line 45: The logic for <counter_out> does
> not match a known FF or Latch template. The description style you are using
> to describe a register or latch is not supported in the current software
> release.
> ERROR:Xst:899 - "numarator9.v" line 44: The logic for <carry_out> does not
> match a known FF or Latch template. The description style you are using to
> describe a register or latch is not supported in the current software
> release.
> Can someone help me and tell me what's wrong about my code?
(snip)
First, the indenting is very confusing.
> always @ (posedge clock or negedge reset)
So, asynchronous reset, since it is in the sensitivity list.
> begin : COUNTER
> if (enable == 1'b1) begin
> a<=1'b1;
> end
> else begin a<=1'b0;
> end
But it is dependent on enable? I believe you can have either
asynchronous or synchronous reset, but not some of each.
> if (reset == 1'b0) begin
> counter_out <= preset;
> carry_out<= 1'b0;
> a<=1'b0;
> end
Try to make a very simple counter, with either asynchronous or
synchronous reset, and a count enable. It has to match what the
real FF's in the real FPGAs do.
> else if (a == 1'b1) begin
> counter_out <= counter_out - 1;
> end
> if(counter_out==4'b0)begin
> carry_out<=~carry_out;
> counter_out<= counter_out + 9;
> end
> else begin
> carry_out<=1'b0;
> end
-- glen
Article: 153760
I'm trying to make a simple PCI interface in a XC6SLX45. In the end
I'll probably go with the premade Xilinx core but I wanted to get
familiar with the details first. It seems that the chip simply cannot
meet the timing for this under any circumstances. I've use the UCF
pinouts created for the xilinx core hoping this includes some magic.
Creating a simple do nothing design that essentially registers frame_n
and pipes it out of trdy_n using a BUFIO2 clock i was able to achieve
this:
Slack (slowest paths): -0.671ns (requirement - (clock arrival + clock
path + data path + uncertainty))
Source: Inst_pci_wrapped/pci_trdy_o_int (FF)
Destination: TRDY_N (PAD)
Source Clock: clk_buf rising at 0.000ns
Requirement: 7.000ns
Data Path Delay: 4.597ns (Levels of Logic = 1)
Clock Path Delay: 3.049ns (Levels of Logic = 2)
Clock Uncertainty: 0.025ns
Clock Uncertainty: 0.025ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2
+ PE
Total System Jitter (TSJ): 0.050ns
Total Input Jitter (TIJ): 0.000ns
Discrete Jitter (DJ): 0.000ns
Phase Error (PE): 0.000ns
Maximum Clock Path at Slow Process Corner: PCLK to Inst_pci_wrapped/
pci_trdy_o_int
Location Delay type Delay(ns) Physical
Resource
Logical
Resource(s)
-------------------------------------------------
-------------------
L4.I Tiopi 1.040 PCLK
PCLK
PCLK_IBUF
ProtoComp8.IMUX.12
BUFIO2_X1Y15.I net (fanout=1) 0.413 PCLK_IBUF
BUFIO2_X1Y15.IOCLK Tbufcko_IOCLK 0.096 bufio2_inst
bufio2_inst
OLOGIC_X0Y59.CLK0 net (fanout=2) 1.500 clk_buf
-------------------------------------------------
---------------------------
Total 3.049ns (1.136ns
logic, 1.913ns route)
(37.3% logic,
62.7% route)
Maximum Data Path at Slow Process Corner: Inst_pci_wrapped/
pci_trdy_o_int to TRDY_N
Location Delay type Delay(ns) Physical
Resource
Logical
Resource(s)
-------------------------------------------------
-------------------
OLOGIC_X0Y59.OQ Tockq 0.842
Inst_pci_wrapped/pci_trdy_o_int
Inst_pci_wrapped/pci_trdy_o_int
M3.O net (fanout=1) 0.234
Inst_pci_wrapped/pci_trdy_o_int
M3.PAD Tioop 3.521 TRDY_N
Inst_pci_wrapped/trdy_buf_inst/OBUFT
TRDY_N
-------------------------------------------------
---------------------------
Total 4.597ns (4.363ns
logic, 0.234ns route)
(94.9% logic,
5.1% route)
It seems unlikely to me that any of that can be removed, and it is not
even close to the 6ns clock to out that I need. Am I missing
something? How can 66mhz pci timing possibly be met in a device with
3.5ns Tioop?
Article: 153761this should be a 4 bit down counter with asyncronous reset(0 active),with an enable that plays the role of a 'start' for the counter(that's why I chose to change the value of "a" depending on enable because enable isn't always "1"->in my project enable= out_of_a_clock_devider & out of a DFF which has as inputs "start" and "stop") I just can't make this counter work..in modelsim everything is fine... If anyone knows how to fix it..please help me... --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153762
>this should be a 4 bit down counter with asyncronous reset(0 active),with >an enable that plays the role of a 'start' for the counter(that's why I >chose to change the value of "a" depending on enable because enable isn't >always "1"->in my project enable= out_of_a_clock_devider & out of a DFF >which has as inputs "start" and "stop") >I just can't make this counter work..in modelsim everything is fine... >If anyone knows how to fix it..please help me... > >--------------------------------------- >Posted through http://www.FPGARelated.com > I forgot to say that when I reset it, the counter has to take the preset value and start countering from that value - that's why I have a preset there. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153763
Legalex <andreiopariuc@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > this should be a 4 bit down counter with asyncronous reset(0 active),with > an enable that plays the role of a 'start' for the counter(that's why I > chose to change the value of "a" depending on enable because enable isn't > always "1"->in my project enable= out_of_a_clock_devider & out of a DFF > which has as inputs "start" and "stop") I think part of the problem related to enable. It is hard to follow the logic through a, and maybe the tools also can't figure that out, but you don't want enable to apply to the reset, otherwise it isn't an asynch reset. I think that is part of the problem. You might also need enable in the sensitivity list, otherwise, and being inside the always block, the assignment to a is also a register. Actually, remove a. Just do all the assignments based on clock, reset, and enable, and be sure that reset applies independent of clock and enable. -- glenArticle: 153764
On May 16, 12:42=A0am, "Legalex" <andreiopariuc@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > >this should be a 4 bit down counter with asyncronous reset(0 active),wit= h > >an enable that plays the role of a 'start' for the counter(that's why I > >chose to change the value of "a" depending on enable because enable isn'= t > >always "1"->in my project enable=3D out_of_a_clock_devider & out of a DF= F > >which has as inputs "start" and "stop") > >I just can't make this counter work..in modelsim everything is fine... > >If anyone knows how to fix it..please help me... > > >--------------------------------------- > >Posted throughhttp://www.FPGARelated.com > > I forgot to say that when I reset it, the counter has to take the preset > value and start countering from that value - that's why I have a preset > there. > > --------------------------------------- > Posted throughhttp://www.FPGARelated.com Does your target device allow presetting to a variable (non-constant) value? (probably not). Follow the templates in the user guide, at least until you get a better idea of what works and what does not. Your enable and reset logic is messed up. Think about priorities of inputs. (e.g. highest priority is reset, second is (clocked) enable, etc.) Code accordingly (e.g. if-else). For example, you reset, but then you run other code that affects those same outputs, negating the effect of reset. When you say it is fine in modelsim, did you actually simulate it (thoroughly) and the results are good, or did you just compile it? This is not a language issue (modelsim compiles it), it is an issue where you are not properly describing the behavior of hardware that can be constructed in your target FPGA. AndyArticle: 153765
In modelsim it worked with testbench and all..the results were good
I re-wrote the code like this but it still gives me those errors :(
module counter9 (
clock ,
reset ,
enable ,
counter_out,
carry_out,
preset
);
input clock ;
input reset ;
input enable ;
input [3:0] preset;
output [3:0] counter_out ;
output carry_out;
wire clock ;
wire reset ;
wire enable ;
wire [3:0] preset;
reg [3:0] counter_out ;
reg carry_out;
always @ (posedge clock or negedge reset or posedge enable)
begin : COUNTER
if (reset == 1'b0) begin
counter_out <= preset;
carry_out<= 1'b0;
end
else if (enable == 1'b1) begin
counter_out <= counter_out - 1;
if(counter_out==4'b0)begin
carry_out<=~carry_out;
counter_out<= counter_out + 9;
end
else begin
carry_out<=1'b0;
end
end
end
endmodule
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 153766"Legalex" <andreiopariuc@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> writes: > this should be a 4 bit down counter with asyncronous reset(0 active),with > an enable that plays the role of a 'start' for the counter(that's why I > chose to change the value of "a" depending on enable because enable isn't > always "1"... So how does assigning 'enable' to 'a' synchronously make enable work like 'start'? If enable is a pulse that should make the counter run forever then I don't think you have the right logic for that. As for the little synthesis problem(s), you describe a counter that can both decrement the counter and increment by 9, at the same time. Fairly exotic hardware, that. Similar thing with a. Hence the error message from XST. This is why logic is usually described so that you have one top level if in an always block. One branch for reset, the other for the interesting stuff. Within the same level in an if structure you can contradict your assignments to your heart's content and the last one will be in force at the end of the clock cycle. Just be sure that's what you wanted.Article: 153767
>What's the big deal about a latch? > It's usually harder to meet Static Timing Analysis with latches. They are as troublesome as a very troublesome thing. If you think you need to use one, think again. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153768
> It seems unlikely to me that any of that can be removed, and it is not > even close to the 6ns clock to out that I need. Am I missing > something? How can 66mhz pci timing possibly be met in a device with > 3.5ns Tioop? You're right. Spartan 6 only supports 33 MHz PCI. See table 1 in DS206, LogiCORE IP 32-Bit Initiator/Target v3 & v4 for PCI. www.xilinx.com/support/documentation/ip_documentation/pci32/v4_16/pci_32_ds206.pdfArticle: 153769
On May 16, 6:03=A0am, "Legalex"
<andreiopariuc@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
> In modelsim it worked with testbench and all..the results were good
>
> I re-wrote the code like this but it still gives me those errors :(
>
> module counter9 (
> =A0 clock ,
> =A0 reset ,
> =A0 enable ,
> =A0 counter_out,
> =A0 carry_out,
> =A0 preset
> =A0 );
>
> =A0 input =A0clock ;
> =A0 input reset ;
> =A0 input enable ;
> =A0 input [3:0] preset;
> =A0 output [3:0] counter_out ;
> =A0 output carry_out;
> =A0 wire clock ;
> =A0 wire reset ;
> =A0 wire enable ;
> =A0 wire [3:0] preset;
> =A0 reg [3:0] counter_out ;
> =A0 reg carry_out;
>
> =A0 always @ (posedge clock or negedge reset or posedge enable)
> =A0 begin : COUNTER
>
> =A0 =A0 =A0 =A0 if (reset =3D=3D 1'b0) begin
> =A0 =A0 =A0 counter_out <=3D =A0preset;
> =A0 =A0 =A0 carry_out<=3D 1'b0;
> =A0 =A0 end
>
> =A0 =A0 else if (enable =3D=3D 1'b1) begin
> =A0 =A0 =A0 counter_out <=3D =A0 counter_out - 1;
>
> =A0if(counter_out=3D=3D4'b0)begin
> =A0carry_out<=3D~carry_out;
> =A0 =A0 counter_out<=3D counter_out + 9;
> =A0 =A0 end
> =A0 =A0 else begin
>
> =A0 =A0 carry_out<=3D1'b0;
> =A0 =A0 end
> =A0 =A0 =A0 =A0 =A0end
>
> =A0 end
> endmodule
>
> ---------------------------------------
> Posted throughhttp://www.FPGARelated.com
Your problem is that you are not creating code that can be mapped into
standard register logic. In this latest version you have a clock,
asynchronous enable and a dyanmic asynchronous reset/preset and this
doesn't exist in the real world.
As a first step towards writing robust and easily timed code avoid the
use of asynchronous resets/presets unless they are absolutely
necessary and use a synchronous reset/preset instead.
---- Code Begin ----
always @ (posedge clock)
begin : COUNTER
if (reset =3D=3D 1'b0) begin
counter_out <=3D preset;
carry_out <=3D 1'b0;
end
else if (enable =3D=3D 1'b1) begin
if (counter_out =3D=3D 4'b0) begin
counter_out <=3D 9;
carry_out <=3D 1'b1;
end
else begin
counter_out <=3D counter_out - 1;
carry_out <=3D 1'b0;
end
end
end
----- Code End -----
Ed McGettigan
--
Xilinx Inc.
Article: 153770On May 16, 12:58=A0pm, smit...@gmail.com wrote: > > It seems unlikely to me that any of that can be removed, and it is not > > even close to the 6ns clock to out that I need. Am I missing > > something? How can 66mhz pci timing possibly be met in a device with > > 3.5ns Tioop? > > You're right. Spartan 6 only supports 33 MHz PCI. See table 1 in DS206, L= ogiCORE IP 32-Bit Initiator/Target v3 & v4 for PCI. > > www.xilinx.com/support/documentation/ip_documentation/pci32/v4_16/pci... Thanks. That would explain it! I had assumed that since it could be done in S3E that it would be a breeze in S6.Article: 153771
"RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote in
message news:kt-dnRe2Lb2cTi7SnZ2dnUVZ_rydnZ2d@giganews.com...
> >What's the big deal about a latch?
>>
>
> It's usually harder to meet Static Timing Analysis with latches.
> They are as troublesome as a very troublesome thing.
> If you think you need to use one, think again.
In this particular case, it's grabbing a rather large 100 ns tick count, to
inject into a message as a timestamp later. Timing isn't an issue. The only
concern was relative space efficiency. There seems no difference between a
latch and FDE, eating up a slice every 2 bits.
I "solved" the other problem of serializing the multi-word timestamps by
sending 8-bit counts after the first full timestamp. The question remains,
though, how to efficiently byte-serialize the large data word. I hate to
hand write a state machine to do this, for every word size I might
encounter. Shifting the latched value seems unnecessarily painful.
Rotating a single hot bit in a surrogate shadow word, one bit representing a
data byte, seems so far the best solution, but I can't dream up a way to
generate the required statements to go with it. Rotating the surrogate mask
effectively makes for a cheap, easy one-hot FSM, but I don't have the
language skill to generate the corresponding:
with vmask select
dout <= w(47 downto 40) when b"100000",
dout <= w(39 downto 32) when b"010000",
dout <= w(32 downto 24) when b"001000",
...
Writing one for each N-sized word is tedious and error prone. Any help or
ideas?
Article: 153772WRT latches: With FDE, all timing paths start and/or end at the FDE. With a latch, they don't (e.g. when the latch is transparent). This makes for many more false paths, etc that cause STA to be very conservative, to the point that you often cannot meet timing unless you use a lot of false path constraints. The problem with those is that they (the constraints) are inherently very difficult to verify (that they are correctly stated and applied) except by inspection and manual analysis. Also some (most) FPGA architectures do not have a latch primitive, but use a macro built from one or more LUTs. These circuits are notoriously glitchy in the presence of two or more inputs changing simultaneously, especially likely since upstream logic is often merged into the same LUT. Unless very carefully designed around, this can cause latches to unlatch even though the enable did not change. Short version: it hurts when you do that. WRT your function. If the i argument is known at synthesis time (this includes the index of a for-loop), then no hardware is synthesized at all, just wires. Otherwise, it will just be multiplexers, with no adder or multiplier (multiply/divide by power of two is just a shift, and the addition of 7 to a number that is already known to have zeroes in the least three bits does not take an adder, just a lut that always outputs 1, which may be shared with others, and some more wires). I do not understand your last question. AndyArticle: 153773
"Andy" <jonesandy@comcast.net> wrote in message news:2afbb4b2-b865-4f40-b706-4cd60365535d@t35g2000yqd.googlegroups.com... > WRT your function. If the i argument is known at synthesis time (this > includes the index of a for-loop), then no hardware is synthesized at > all, just wires. Otherwise, it will just be multiplexers, with no > adder or multiplier (multiply/divide by power of two is just a shift, > and the addition of 7 to a number that is already known to have zeroes > in the least three bits does not take an adder, just a lut that always > outputs 1, which may be shared with others, and some more wires). Doh! A for loop does seem the obvious answer. Does that synthesize in a clocked process? Thanks.Article: 153774
On Wed, 16 May 2012 15:16:32 -0500 "MikeWhy" <boat042-nospam@yahoo.com> wrote: > "Andy" <jonesandy@comcast.net> wrote in message > news:2afbb4b2-b865-4f40-b706-4cd60365535d@t35g2000yqd.googlegroups.com... > > WRT your function. If the i argument is known at synthesis time (this > > includes the index of a for-loop), then no hardware is synthesized at > > all, just wires. Otherwise, it will just be multiplexers, with no > > adder or multiplier (multiply/divide by power of two is just a shift, > > and the addition of 7 to a number that is already known to have zeroes > > in the least three bits does not take an adder, just a lut that always > > outputs 1, which may be shared with others, and some more wires). > > Doh! A for loop does seem the obvious answer. Does that synthesize in a > clocked process? > > Thanks. > It does if it's synthesizable. More specifically, if the loop can be unrolled into some mess of combinational logic, then that logic can be placed in front of a register, and the for loop can be synthesized. If there is no combinational logic that would generate that function (or if there is, but it's enormous, e.g. a divider) then you can't synthesize it. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
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