Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 120500

Article: 120500
Subject: HELP with Asynch RAM
From: Frank <FrankTDai@gmail.com>
Date: Thu, 07 Jun 2007 21:50:23 -0700
Links: << >>  << T >>  << A >>
PLEASE HELP:

In my design I have a bank of memory made up of 64 reg[31:0]'s. They
get synthesized into latches, and kill my timing because of a huge 64
X 32 sensitivity list.(See below).

How else can I synthesize a 64X32 block of Memory with Asynch Read,
Asynch Write, and where the Data_In shows up immediately on the
Data_Out?

Can I do it with Xilinx CoreGen Modules?


//This part handles the read for the 64 32-bit registers which store
the data.
//The rd_address is 1-hot, 64-bit reg.

always @ (rd_address or q0 or q1 or q2 or q3 or q4 or q5 or q6 or q7
                     or q8 or q9 or qa or qb or qc or qd or qe or qf
                     or q10 or q11 or q12 or q13 or q14 or q15 or q16
or q17
                     or q18 or q19 or q1a or q1b or q1c or q1d or q1e
or q1f
                     or q20 or q21 or q22 or q23 or q24 or q25 or q26
or q27
                     or q28 or q29 or q2a or q2b or q2c or q2d or q2e
or q2f
                     or q30 or q31 or q32 or q33 or q34 or q35 or q36
or q37
                     or q38 or q39 or q3a or q3b or q3c or q3d or q3e
or q3f)
          begin
            case (1'b1) // synopsys full_case parallel_case
              rd_address[0]:    DO = q0;
              rd_address[1]:    DO = q1;
              rd_address[2]:    DO = q2;
              rd_address[3]:    DO = q3;
              rd_address[4]:    DO = q4;
              rd_address[5]:    DO = q5;
              rd_address[6]:    DO = q6;
              rd_address[7]:    DO = q7;
              rd_address[8]:    DO = q8;
              rd_address[9]:    DO = q9;
              rd_address[10]:    DO = qa;
              rd_address[11]:    DO = qb;
              rd_address[12]:    DO = qc;
              rd_address[13]:    DO = qd;
              rd_address[14]:    DO = qe;
              rd_address[15]:    DO = qf;
              rd_address[16]:    DO = q10;
              rd_address[17]:    DO = q11;
              rd_address[18]:    DO = q12;
              rd_address[19]:    DO = q13;
              rd_address[20]:    DO = q14;
              rd_address[21]:    DO = q15;
              rd_address[22]:    DO = q16;
              rd_address[23]:    DO = q17;
              rd_address[24]:    DO = q18;
              rd_address[25]:    DO = q19;
              rd_address[26]:    DO = q1a;
              rd_address[27]:    DO = q1b;
              rd_address[28]:    DO = q1c;
              rd_address[29]:    DO = q1d;
              rd_address[30]:    DO = q1e;
              rd_address[31]:    DO = q1f;
              rd_address[32]:    DO = q20;
              rd_address[33]:    DO = q21;
              rd_address[34]:    DO = q22;
              rd_address[35]:    DO = q23;
              rd_address[36]:    DO = q24;
              rd_address[37]:    DO = q25;
              rd_address[38]:    DO = q26;
              rd_address[39]:    DO = q27;
              rd_address[40]:    DO = q28;
              rd_address[41]:    DO = q29;
              rd_address[42]:    DO = q2a;
              rd_address[43]:    DO = q2b;
              rd_address[44]:    DO = q2c;
              rd_address[45]:    DO = q2d;
              rd_address[46]:    DO = q2e;
              rd_address[47]:    DO = q2f;
              rd_address[48]:    DO = q30;
              rd_address[49]:    DO = q31;
              rd_address[50]:    DO = q32;
              rd_address[51]:    DO = q33;
              rd_address[52]:    DO = q34;
              rd_address[53]:    DO = q35;
              rd_address[54]:    DO = q36;
              rd_address[55]:    DO = q37;
              rd_address[56]:    DO = q38;
              rd_address[57]:    DO = q39;
              rd_address[58]:    DO = q3a;
              rd_address[59]:    DO = q3b;
              rd_address[60]:    DO = q3c;
              rd_address[61]:    DO = q3d;
              rd_address[62]:    DO = q3e;
              rd_address[63]:    DO = q3f;


Article: 120501
Subject: Re: LVPECL output skew
From: "Bob" <nimby_NEEDSPAM@roadrunner.com>
Date: Thu, 7 Jun 2007 22:04:30 -0700
Links: << >>  << T >>  << A >>

<Mavrick> wrote in message news:eea754b.4@webx.sUN8CHnE...
> Bob,
>
> As per my understanding using the bufio the fpga internal clock tree skew 
> is 50 ps. I am still not able to understand the 10 ps skew per fpga output 
> pin and you multiply that by the number of outputs used. Is this 10ps skew 
> due to mismatch in trace routing inside the fpga? If so why we need to 
> multiiply by the number of pins used?
>
> Mavrick

The thing that drives a global clock line is a BUFG (aka, BUFGMUX). Each 
clock line is driven from one end (as far as I know) and the IOBs tap off of 
this (long) clock line. So, as a given clock edge moves down the clock line 
it passes by the IOBs. Each IOB gets this clock edge a little later than the 
previous one, so an output generated (clocked out) by that IOB is delayed (a 
little) from the previous one. It's that simple.

Bob 



Article: 120502
Subject: Re: HELP with Asynch RAM
From: ARH <haghdoost@gmail.com>
Date: Thu, 07 Jun 2007 22:40:55 -0700
Links: << >>  << T >>  << A >>
On Jun 8, 7:50 am, Frank <FrankT...@gmail.com> wrote:
> PLEASE HELP:
>
> In my design I have a bank of memory made up of 64 reg[31:0]'s. They
> get synthesized into latches, and kill my timing because of a huge 64
> X 32 sensitivity list.(See below).
>
> How else can I synthesize a 64X32 block of Memory with Asynch Read,
> Asynch Write, and where the Data_In shows up immediately on the
> Data_Out?
>
> Can I do it with Xilinx CoreGen Modules?
>
> //This part handles the read for the 64 32-bit registers which store
> the data.
> //The rd_address is 1-hot, 64-bit reg.
>
> always @ (rd_address or q0 or q1 or q2 or q3 or q4 or q5 or q6 or q7
>                      or q8 or q9 or qa or qb or qc or qd or qe or qf
>                      or q10 or q11 or q12 or q13 or q14 or q15 or q16
> or q17
>                      or q18 or q19 or q1a or q1b or q1c or q1d or q1e
> or q1f
>                      or q20 or q21 or q22 or q23 or q24 or q25 or q26
> or q27
>                      or q28 or q29 or q2a or q2b or q2c or q2d or q2e
> or q2f
>                      or q30 or q31 or q32 or q33 or q34 or q35 or q36
> or q37
>                      or q38 or q39 or q3a or q3b or q3c or q3d or q3e
> or q3f)
>           begin
>             case (1'b1) // synopsys full_case parallel_case
>               rd_address[0]:    DO = q0;
>               rd_address[1]:    DO = q1;
>               rd_address[2]:    DO = q2;
>               rd_address[3]:    DO = q3;
>               rd_address[4]:    DO = q4;
>               rd_address[5]:    DO = q5;
>               rd_address[6]:    DO = q6;
>               rd_address[7]:    DO = q7;
>               rd_address[8]:    DO = q8;
>               rd_address[9]:    DO = q9;
>               rd_address[10]:    DO = qa;
>               rd_address[11]:    DO = qb;
>               rd_address[12]:    DO = qc;
>               rd_address[13]:    DO = qd;
>               rd_address[14]:    DO = qe;
>               rd_address[15]:    DO = qf;
>               rd_address[16]:    DO = q10;
>               rd_address[17]:    DO = q11;
>               rd_address[18]:    DO = q12;
>               rd_address[19]:    DO = q13;
>               rd_address[20]:    DO = q14;
>               rd_address[21]:    DO = q15;
>               rd_address[22]:    DO = q16;
>               rd_address[23]:    DO = q17;
>               rd_address[24]:    DO = q18;
>               rd_address[25]:    DO = q19;
>               rd_address[26]:    DO = q1a;
>               rd_address[27]:    DO = q1b;
>               rd_address[28]:    DO = q1c;
>               rd_address[29]:    DO = q1d;
>               rd_address[30]:    DO = q1e;
>               rd_address[31]:    DO = q1f;
>               rd_address[32]:    DO = q20;
>               rd_address[33]:    DO = q21;
>               rd_address[34]:    DO = q22;
>               rd_address[35]:    DO = q23;
>               rd_address[36]:    DO = q24;
>               rd_address[37]:    DO = q25;
>               rd_address[38]:    DO = q26;
>               rd_address[39]:    DO = q27;
>               rd_address[40]:    DO = q28;
>               rd_address[41]:    DO = q29;
>               rd_address[42]:    DO = q2a;
>               rd_address[43]:    DO = q2b;
>               rd_address[44]:    DO = q2c;
>               rd_address[45]:    DO = q2d;
>               rd_address[46]:    DO = q2e;
>               rd_address[47]:    DO = q2f;
>               rd_address[48]:    DO = q30;
>               rd_address[49]:    DO = q31;
>               rd_address[50]:    DO = q32;
>               rd_address[51]:    DO = q33;
>               rd_address[52]:    DO = q34;
>               rd_address[53]:    DO = q35;
>               rd_address[54]:    DO = q36;
>               rd_address[55]:    DO = q37;
>               rd_address[56]:    DO = q38;
>               rd_address[57]:    DO = q39;
>               rd_address[58]:    DO = q3a;
>               rd_address[59]:    DO = q3b;
>               rd_address[60]:    DO = q3c;
>               rd_address[61]:    DO = q3d;
>               rd_address[62]:    DO = q3e;
>               rd_address[63]:    DO = q3f;

Hi

Two of the most over used and abused directives included in Verilog
models are the directives "//synopsys full_case parallel_case". The
popular myth that exists surrounding "full_case
parallel_case" is that these Verilog directives always make designs
smaller, faster and latch-free. This is false! Indeed, the "full_case
parallel_case" switches frequently make designs larger and
slower and can obscure the fact that latches have been inferred .
These switches can also change the functionality of a design causing a
mismatch between pre-synthesis and post-synthesis
simulation, which if not discovered during gate-level simulations will
cause an ASIC to be taped out with design problems.

it is generally a bad coding practice to give the synthesis tool
different information about the functionality of a design than is
given to the simulator.

Whenever either "full_case" or "parallel_case" directives are added to
the Verilog source code, more information is potentially being given
about the design to the synthesis tool than is being given to the
simulator

In general, do not use "full_case parallel_case" directives with any
Verilog case statements.



 ARH


Article: 120503
Subject: Re: A first FPGA project
From: Mark McDougall <markm@vl.com.au>
Date: Fri, 08 Jun 2007 16:00:40 +1000
Links: << >>  << T >>  << A >>
cs_posting@hotmail.com wrote:

> You might want to think about using a flash memory card instead of a 
> physical disk... a bit more reliable and even easier to source today.

Agreed.

> If you are only handling a sector, you may be able to use a state- 
> machine like architecture rather than a processor core.  All you really
> have to do is grab the data from one sector quickly, and then let the
> 8080 read it out more slowly.  

I've actually implemented a read-only (state machine) emulation of the
WDC-1793 in an FPGA which sources data from a serial flash device. It
interfaces to a TRS-80 implemented within the same FPGA. So state-machine
is definitely an option.

> I would assume controllers of that vintage would be state machines and 
> not microprogrammed machines... but then I could be wrong.

IIUC the WDC 1793 did actually have a (purpose-built?) microprocessor.

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 120504
Subject: Re: Arbiter
From: "jtw" <wrightjt @hotmail.invalid>
Date: Fri, 08 Jun 2007 06:07:26 GMT
Links: << >>  << T >>  << A >>
Eric asked 'how' you would do it with logic gates.  Once you know that, then 
the question is to how to describe that behavior in VHDL, verilog, c, c++...

If you can write behavioral descriptions for your FFs and logic gates in 
VHDL (etc.), you have a solution to your problem.

If you can abstract the sequence to a state machine, and code that in VHDL 
(etc.), you have another solution to your problem.

If you understand what it is you really want to do, and appropriately 
describe and code it, you are likely to have a better solution to your 
problem.  A better solution, because it will respond to other sequences the 
way you intend, rather than just matching the small set of stimulus-response 
vectors described.  There will be many solutions that will pass the test 
vectors, but will not 'do the right thing' in general.

JTW

<willwestward@gmail.com> wrote in message 
news:1181261769.985939.84080@x35g2000prf.googlegroups.com...
> On Jun 7, 3:54 pm, Eric Smith <e...@brouhaha.com> wrote:
>> willwestw...@gmail.com writes:
>> > I hope I explained ok here. I'm having trouble putting this behavior
>> > into codes in VHDL. Someone has any idea?
>>
>> How would you design it with logic gates (and flip-flops, if required)?
>>
>> Once you know that, you can just do the same thing in VHDL.
>
> Yes you can do it in logic gates, but I want behavior modeling. If
> using FF and logic gates, it would make this totally a netlist
> coding.
>
> Here is the Requset, Reset, and Acknowledge again:
>
> Request(0 to 3): 0000 1010 0110 1101 0010 1001 0001 1000 1011 1011
> 1000 0101 1001
> Reset:
> HHHHLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLHHHHLLLLLLLLLLLLLLLLLLLLL
> Ack(0 to 3):     0000 1000 0010 0100 0010 1000 0001 1000 0000 1000
> 1000 0100 0001
>
> I also plan to convert this code into Verilog, C or C++ later on, so
> if you have algorithm or codes in those languages, it's fine too.
>
> 



Article: 120505
Subject: Re: Power PC heap initialisation on Reset
From: "sjulhes" <t@aol.fr>
Date: Fri, 8 Jun 2007 08:48:01 +0200
Links: << >>  << T >>  << A >>
Thanks for your answer, we're working on it !


"Peter Ryser" <peter.ryser@xilinx.com> a écrit dans le message de news: 
f47n98$pa91@cnn.xilinx.com...
> For standalone applications the heap is initialized in sbrk.c which you 
> can find in ppc405_0/libsrc/standalone*/src/sbrk.c
>
> You can see that heap_ptr is initialized on the first call to sbrk() and 
> increases its value after that on every call. It maintains its value 
> through a reset.
>
> To change the behavior you can copy sbrk.c into your own project and 
> change it.
>
>
> Alternatively, there might also be a compiler option that allows you to 
> initialize static values at run time instead of compile time. You might be 
> able to
> static char *heap_ptr=0;
> in combination with the compiler option to get the desired behavior.
>
> - Peter
>
>
> sjulhes wrote:
>> Hi all,
>>
>> I have a SOC with a Power PC running on a Virtex II pro.
>> On FPGA configuration, the PPC firmware runs correctly, heap reservation 
>> on firmware initialisation is correct.
>> When I reset the SOC with the reset controller, the PPC restarts 
>> correctly, but when it tries to use the heap to initialize some dynamic 
>> variables, I get a fail on the malloc.
>>
>> It seem that on the reset the power PC context is not reinitialized.
>> I guess we have to add something in the boot sequence of the PPC to reset 
>> the heap pointer.
>>
>> I'm I right ?
>> It is something that must be standard in the power PC world, does someone 
>> have an exemple how to do this ??
>>
>> Thanks.
>>
>> Stéphane. 



Article: 120506
Subject: adaptive filter FPGA
From: "cutemonster" <ckh827@hotmail.com>
Date: Fri, 08 Jun 2007 02:06:33 -0500
Links: << >>  << T >>  << A >>

thanks for looking and please help me.

I have a 16 bit ADC sampling at 50Mhz.  I take only 10 MSB and display it
in my video 1024 x 768 as an output to check the signal.  I see a
continuous line displayed in my monitor which still toggle within 1 or 2
pixels.  My question is, do I need a adaptive filter to really smooth the
line in only 1 pixel wide?  To make my question clear, for example
whenever it's supposed to be a horizontal line, it has noise random 2
pixel wide in y.  Is this situation, how can I smooth the data
efficiently?  I used moving average to smooth the data but every pixel is
important,  my moving average will give me a small wave along a straight
line plus curving the edge. 

The input from ADC is dc coupled which accept level of dc voltage
continuously.  I'm really doubt about FIR filter and adaptive filter and
can somebody tell me is this should be done in adaptive filter?  I tried
the DA fir from xilinx spartan 3 but it distort the signal, is that mean
my cut off frequency is too low?  And i use 10bit as input of adaptive
filter, should I should all 16 bit as input?


Article: 120507
Subject: Re: What's the smallest/fastest CLB/Slice/Lut based unsigned integer 64 bit by 64 bit multiplier/squarer design?
From: Totally_Lost <air_bits@yahoo.com>
Date: Fri, 08 Jun 2007 00:42:36 -0700
Links: << >>  << T >>  << A >>
On Jun 7, 10:24 am, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:
> All of these architectures require N*N/K 1-bit adders when multiplying
> N bit numbers in K clock cycles.


Hi Kolja,

Without a doubt the product of two numbers of length M and N, yields
at most M*N full adders, and LUT's, by most decompositions we teach
students ... or N*N = N^2 in your form. For the product of two 64
bits, that yield roughly 4096 LUTs using the basic student forms which
are taught in most EE courses. Actually, it's (N-1) rows of adders of
length N, or 4064 full adders or LUTs.

However, that is about what we expect from students, and novice
engineers which fail to study best practice algorithms, and think
about the problem in a bit more detail.

Karatsuba's form requires two products of (N/2) plus a product of ((N/
2)+1) bits, plus three more adders of length (M/2)+1, plus some
careful merging of the data streams. Roughly 992+992+1056+99=3139 full
adders, or LUTs which is a significant savings over N^2.  A good
student would produce this result without question.

An excellent student would recursively implement the two 32 bit
multiplies using Karatsuba's form as well, saving roughly another 378
full adders or LUTs, for a rough total of 2761 LUTs. And probably one
more time to pickup another hundred or so full adders, or LUTs, but
also to better constrain the input routing and locality. One of the
side effects of using Karatsuba's form, is that it reduces the fan-in
required for the input digits, and greatly relieves input routing over
a basic student form solution where every input term is in a full N
bit row or column.

It's with this starting point, significantly better than N^2, (about
60% the size of the basic student adder tree from) that we can do even
better with careful optimization and layout, using a host of salty dog
tricks to implement a a slightly better variation of this model.



Article: 120508
Subject: Pin Capacitance Quartus 6.0
From: fpga.vhdl.designer@gmail.com
Date: Fri, 08 Jun 2007 00:53:26 -0700
Links: << >>  << T >>  << A >>
I have a warning with Quartus 6.0 software in the Fitter section.

It says : "Found 71 ouput pins without output pin load capacitance
assignment"

In the "Device and Pin Options" I can see that in the LVTLL the
"Capacitive loading" there's 0 !

I don't know what capacitive loading I must put in my case.

The device is a Stratix II EP2S15F484C5 mounted on our board...

Thanks...


Article: 120509
Subject: SOLVED!!! Symbolic names for pll derived clocks in SDC file? (quartus)
From: wzab <wzab01@gmail.com>
Date: Fri, 08 Jun 2007 01:32:55 -0700
Links: << >>  << T >>  << A >>
Thanks.
What I need is to have the phase relationship automatically updated,
whenever I change
any settings in the PLL.

Anyway my questions was probably stupid.
It can be done just with the features of the Tcl:

derive_pll_clocks

set out_clk80 "out_clk_pll_1|altpll_component|pll|clk[0]"
set out_clk80_latch "out_clk_pll_1|altpll_component|pll|clk[1]"
set out_clk80_data "out_clk_pll_1|altpll_component|pll|clk[2]"

then:


set_output_delay -clock $out_clk80_latch -add_delay 1.0 [get_ports
{IFIFO_OUT_DPRSNT}]
set_output_delay -clock $out_clk80_latch -add_delay 1.0 [get_ports
{IFIFO_OUT_CT[1]}]

--
Thanks & Regards,
Wojtek


Article: 120510
Subject: Re: What's the smallest/fastest CLB/Slice/Lut based unsigned integer 64 bit by 64 bit multiplier/squarer design?
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Fri, 8 Jun 2007 09:42:31 +0100
Links: << >>  << T >>  << A >>

"Totally_Lost" <air_bits@yahoo.com> wrote in message 
news:1180769858.872726.132740@i13g2000prf.googlegroups.com...
> I've been looking at the various core/macro generators and they all
> seem horribly large and slow, almost like student designs. Has anyone
> seriously taken a good look at hand fitting multipliers and squarers
> into Altera/Xilinx FPGA's?

This has been an interesting thread. But I still wonder why you want to 
implement a LUT-based 64x64 multiplier?

The reason the multiplier generator core in Xilinx Coregen doesn't use a 
whole lot of tricks in this configuration is that it seems like a very 
unlikely use case, and not one worth concentrating a lot of effort on. Ever 
since hard multiplier/DSP blocks began appearing in FPGAs, they have been 
the best building block for these large multiplier structures.

Maybe you can share some details of why exactly you need such a macro?

Cheers,

      -Ben- 



Article: 120511
Subject: TimeQuest - clocks related by default?
From: wzab <wzab01@gmail.com>
Date: Fri, 08 Jun 2007 01:50:23 -0700
Links: << >>  << T >>  << A >>
Hi All,

It is obviously my fault, and the correct answer is probably
"RTFM" (1), but I've just lost significant amount of time, because
TimeQuest treats clocks as related by default.
The design which worked perfectly compiled with standard Timing
Analyzer, got crazy after switching to TQ.
I discovered the problem when I got strange warnings like:

 "Warning: 26 (of 12252) connections in the design require a large
routing delay to achieve hold requirements. Please check the circuit's
timing constraints and clocking methodology, especially multicycles
and gated clocks."

The TQ considers all clocks as related unless specified otherwise.
Is it reasonable to consider two clocks with different frequences
(e.g. 10.3213 MHz and 13.43345 MHz - just the random values) as
related?
In this case there must be ALWAYS ts and th violations.
Shouldn't the TQ loudly complain about not specified relationships
between the clocks instead of assuming by default that all clocks are
related?
--
TIA & Regards,
Wojtek.

(1) qts_qii53019.pdf

Page  7-1: All clocks are related by default. (Refer to "Related and
Unrelated
 Clocks" on page 7-=AD13.)
Page 7-13: Related and Unrelated Clocks
In the Quartus II TimeQuest Timing Analyzer, all clocks are related by
default, and you must add assignments to indicate unrelated clocks.
However, in the Quartus II Classic Timing Analyzer, all base clocks
are
unrelated by default. All derived clocks of a base clock are related
to each
other, but are unrelated to other base clocks and their derived
clocks.

Then on 7-14 it is explained how to set clocks to unrelated with
set_clock_groups -exclusive -group {clock_a} -group {clock_b}


Article: 120512
Subject: Re: Topics and Ideas for BS Project
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: 8 Jun 2007 10:59:32 GMT
Links: << >>  << T >>  << A >>
In news:lgfg635gsikhnj2ps84lv24fs0qpj84mt4@4ax.com timestamped Thu, 07
Jun 2007 18:55:05 +0100, Evan Lavelle <nospam@nospam.com> posted:
     "On 7 Jun 2007 11:02:48 GMT, Colin Paul Gloster
     <Colin_Paul_Gloster@ACM.org> wrote:
     [..]
     >standard. It is very clearly written in Section 4.2.1 The scheduling
     >algorithm:
     >"[..]
     >
     >4.2.1.2 Evaluation phase
     >
     >[..]
     >
     >Since process instances execute without interruption, only a single
     >process instance can be running at any
     >one time, and no other process instance can execute until the
     >currently executing process instance has
     >yielded control to the kernel. [..]
     
     I'm not quite sure what you're saying here, but SystemC would be
     useless if it didn't support a user-level notion of
     concurrency. [..]"

If one thread/process is running and all other threads/processes are
not running, then they are not running concurrently. They are not
running, actually.
     
     "Or are you saying that you can't implement SystemC on concurrent
     hardware/multi-threaded processors/whatever?"

I am not saying that. However, I am not aware of a SystemC(R)
implementation (aside from synthesizers of course) which actually
exploits concurrent hardware (e.g. a multiprocessor workstation). If
you check one of the forums on SystemC.org you can notice people who
were not pleased that their OSCI simulators would use just one
operating system process.


     "[..] But, if you look at 4.2.1 in
     more detail, you'll see that you can implement your scheduler in any
     way you want, as long as you preserve the simulation semantics. See
     note 3 in 4.2.1.2:
     
     "3  An implementation running on a machine that provides hardware
     support for concurrent processes may permit two
     or more processes to run concurrently provided that the behavior
     appears identical to the co-routine semantics defined in
     this clause"."

I am aware of that. It is also not necessary to have that written in
the standard: e.g. if a particular function is always called with a
parameter of exactly the same value then it might be optimized to not
bother passing the parameter in so long as the optimized version does
what is required of it. The designer would not even notice.

Are you aware of a SystemC(R) simulation engine which actually does
run threads/processes concurrently? I am aware of one which does
not. I do not contend that concurrency can not be achieved by a
SystemC(R) simulation engine, but before such a simulator is made, it
will be imaginary. Do people really want to bother? The SystemC(R)
standard was being drafted for years. How many more years until
concurrent simulations?
     
     "Besides, there's nothing wrong with non-preemptive coroutine
     semantics."

True. Sequential programming can be useful.

     "Why would you want to pre-empt an executing thread? [..]"

Perhaps I would, perhaps I would not. It depends on what I am tying to
do. Preemptive multitasking operating systems do exist. I spoke about
concurrency whereas both preempting something and non-preemptive
coroutine semantics involve sequential programming which is not concurrent.
     
     "[..]
     
     BTW, what is SystemC(R)? 'SystemC' is an OSCI trademark, in the same
     way that 'Verilog' is a Cadence trademark."

Terms and/or conditions similar to what were imposed on me can be
found on
WWW.SystemC.org/account/register.php
, such as:
"[..]

EXHIBIT D

 

Trademark Usage Policy
 
[..]

II.  PROPER USE OF MARKS

 

Trademarks and service marks function as adjectives and generally
should not be used as nouns [..]
[..]

III.  PROPER ATTRIBUTION
Trademark ownership is attributed in two ways, with the use of a
symbol [..]

[..]"

ASCII does not have a registered trademark character, so "(R)" can
suffice instead.

Regards,
Colin Paul Gloster

Article: 120513
Subject: Re: FPGA / Virtex II Pro / LWIP
From: Patrick Dubois <prdubois@gmail.com>
Date: Fri, 08 Jun 2007 12:33:56 -0000
Links: << >>  << T >>  << A >>
On 7 juin, 21:39, Ken Ryan <newsr...@leesburg-geeks.org> wrote:
> Well, I believe xilkernel is theoretically needed even with raw api.
> In any case, I've never tried raw mode myself, but I thought I saw posts
> in this NG that said raw mode doesn't actually work yet.

lwIP in raw API mode (for the hard temac only, no problem for other
mac) won't be supported before EDK v9.2, due at the end of the summer.
With raw mode you don't need xilkernel.

If you want early temac support for raw mode, you might want to give
the driver Paul Tobias did a try:
http://www.paultobias.com/Xilinx/

Search his post in this NG for more info.

Patrick



Article: 120514
Subject: Re: LVPECL output skew
From: Mavrick <>
Date: Fri, 8 Jun 2007 05:45:23 -0700
Links: << >>  << T >>  << A >>
I like your analogy but we are using bufio to clock the oserdes. The Xilinx spec says that maximum skew with bufio is 50ps. Thus if I drive 40 loads with bufio clock output then the maximum skew should not exceed 50 ps.

Is that correct?

Mavrick

Article: 120515
Subject: Re: EDK9.1: XTemac + LwIP + Xilkernel + unistd.h = possible?
From: Patrick Dubois <prdubois@gmail.com>
Date: Fri, 08 Jun 2007 13:57:04 -0000
Links: << >>  << T >>  << A >>
On 7 juin, 21:29, Ken Ryan <newsr...@leesburg-geeks.org> wrote:
> PatrickDuboiswrote:
> > I
> > sold the idea around here to use the Avnet FX12 mini-module as a nice
> > solution to ethernet connectivity. I thought that there would be lots
> > of working examples for it (as ethernet seems to be its biggest
> > selling point). Wrong.
>
> Hoboy, you stepped on a rant there. :-)
>
> I initially procured the Avnet v2pro FF672 board with the comm3 module.
> I figured, how could I go wrong, there's an example design that does 90%
> of what I want to do - the only bit missing was a specialized gigabit
> serial link that I could adapt from a previous design.
>
> I checked out the board, the example seemed to work OK, so I proceeded
> with my design.  Then sometime later I connected the board to my
> company's intranet - instead of a private wire link.  Wham, the TCP
> stack fell over, crashed the processor hard.  This was my introduction
> to xilnet.  Then I realize that EDK didn't support the 91C111 MAC that
> was on that board - I'd have to port an ethernet stack myself.  The
> Avnet demo was a hacked-up port of xilnet with a very rudimentary
> driver, and completely useless for anything halfway realistic.
>
> I actually started down the path of porting Linux to the board, when I
> discovered another problem.  The comm3 module uses all 3.3V signaling to
> the FPGA.  The FF672 board has a bank voltage select to support it.
> Unfortunately *some* of the I/Os come from a fixed 2.5v bank.  So
> Avnet's stack was driving about a half-dozen 2.5v inputs with 3.3v
> levels.  I considered switching to the comm2 module, but when I looked
> at the schematics I saw the same problem.  Eventually I got hold of
> someone in the know at Avnet; turns out that was a known design bug,
> known for a long time (through two design generations!).
>
> My mood wasn't helped by the complete and utter failure to get their
> SystemAce Module to work (I eventually gave up and tossed it in a drawer
> to rot).
>
> Normally when one uses one of these development boards one is just
> fiddling with it or experimenting.  Sometimes we want to embed it into a
> product, if it's appropriate.  This was to go into some equipment with a
> fairly long expected lifetime, so I couldn't afford to have hardware I
> knew would eat itself.  $4500 and six weeks down the drain.  I turned
> the Avnet sales rep's ears around for that one.  Avnet is great with the
> vast majority of what they do, but it'll be a long time before I
> consider another of their development boards for anything more
> sophisticated than fixing a short table leg.
>
> Now I'm going through the process of finding all the other little
> surprises (I went to an ML405 board; much better piece of hardware
> thought it took me a while to port my rocketio design).
>
> OK, I'll quit frothing now...
>
>         ken

Hehe, thanks for sharing your experience :-)


Article: 120516
Subject: XST net splitting blocks placement
From: David Tweed <dtweed@acm.org>
Date: Fri, 08 Jun 2007 14:27:23 GMT
Links: << >>  << T >>  << A >>
I have a Spartan 3 interfaced to a TigerSHARC via its "link port",
which is a 4-bit wide DDR communications interface. The receive
side of this interface on the FPGA consists of two 16x4 bit FIFOs
implemented as LUTRAM, and the write address of each one is driven
by a 4-bit register, explicitly implemented as FD or FDC.

I added "LOC" constraints to my VHDL source for the four LUTRAMs
and four write-address flip-flops, in order to control skew among
the data lines and to optimize potential performance. I'm currently
running this interface at 125 MHz, but hope to be able to support
250 MHz eventually. In particular, the flip-flops are packed in
pairs, two to a given location.

Anyway, my problem is this: All of this has been working fine for
the last two years while the rest of the FPGA was being developed.
However, on the last iteration of adding some more logic to the
FPGA (unrelated to the DSP link port), I suddenly started getting
an error from the "Directed Packing" step of the Map process saying
that it couldn't pack one of my flip-flops with the other, because
the set/resets were not identical. It turns out that XST had assigned
the reset of one of the flip-flops to a different copy of the global
reset signal, which presumably had been created because the fanout
of the reset signal had reached some threshold. Apparently, the
assignment of loads to specific copies of replicated nets occurs
at an earlier step, and doesn't take into account directed packing
constraints.

So, my question is this: Is there an easy way, in my VHDL source
file, to insure that all of my flip-flops are connected to the
*same* copy of the reset signal, without introducing additional
logic into the path? The file is attached below for reference.

Thanks in advance for any suggestions!

-- Dave Tweed

============================================================================
-- dsp_link_rx.vhd

-- Receive side of a 4-bit wide ADSP-TS201 link port.

-- This is based on the design found in XAPP635, but without the block RAMs
-- used to convert the internal data path to 128 bits width. It is designed
-- to accept one quadword at a time into its LUTRAM 16x8 FIFO. The FIFO can
-- be unloaded at the system clock rate, and then another quadword can be
-- accepted from the DSP transmitter.

-- To do:
--   For now, we're not interested in the BCOMP signal, so it is ignored.

-- History:
--  2007/06/05 DT   Fix sensitivity list.
--  2005/08/19 DT   Fix problem with duplicated last byte.
--  2005/08/17 DT   Fix problem with duplicated first byte.
--  2005/08/10 DT   Eliminate generate statements so that we can label
--                  primitives for placement.
--  2005/08/08 DT   Fix FIFO state machine.
--  2005/08/02 DT   Take over from HDLmaker; fix trigger mechanism.
--  2005/06/07 DT   Move the I/O buffers to the pad ring.
--  2005/05/22 DT   Start.

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;

-- for correct simulation of RAM16X1D
library unisim;
use unisim.vcomponents.all;

entity dsp_link_rx is
     port (
       clock             : in    std_logic;
       rst               : in    std_logic;

       -- external interface from DSP
       lxacko            : out   std_logic;
       lxbcompi          : in    std_logic;
       lxclk             : in    std_logic;
       lxdata            : in    std_logic_vector (3 downto 0);

       -- internal interface (to bytestream decoder, fast version)
       dataout           : out   std_logic_vector (7 downto 0);
       data_en           : out   std_logic;
       ready             : in    std_logic
     );
end dsp_link_rx;

architecture BEHAVIOR of dsp_link_rx is

   -- --------------------------------------------------------------------

   signal high                   : std_logic;
   signal notlxclk               : std_logic;
   signal int                    : std_logic_vector(7 downto 0);
   signal rd_addr                : std_logic_vector(3 downto 0);
   signal wr_addrp_d             : std_logic_vector(3 downto 0);
   signal wr_addrp               : std_logic_vector(3 downto 0);
   signal wr_addrn_d             : std_logic_vector(3 downto 0);
   signal wr_addrn               : std_logic_vector(3 downto 0);

   signal trigger_d              : std_logic;
   signal data_en_int            : std_logic;
   signal set_lxacko             : std_logic;
   signal lxacko_int             : std_logic;

   type fifo_state_t is (fifo_empty, fifo_active, fifo_final);
   signal fifo_state             : fifo_state_t;

   attribute loc                 : string;
   attribute syn_keep            : boolean;

   attribute syn_keep of lxclk : signal is TRUE;

   attribute loc of rp0          : label is "slice_x40y8";
   attribute loc of rp1          : label is "slice_x38y10";
   attribute loc of rp2          : label is "slice_x40y10";
   attribute loc of rp3          : label is "slice_x38y8";
   attribute loc of rn0          : label is "slice_x40y9";
   attribute loc of rn1          : label is "slice_x38y11";
   attribute loc of rn2          : label is "slice_x40y11";
   attribute loc of rn3          : label is "slice_x38y9";

   attribute loc of ff_wr_addrp0 : label is "slice_x39y9";
--  attribute loc of ff_wr_addrp1 : label is "slice_x39y9";
   attribute loc of ff_wr_addrp2 : label is "slice_x39y8";
   attribute loc of ff_wr_addrp3 : label is "slice_x39y8";
   attribute loc of ff_wr_addrn0 : label is "slice_x41y9";
   attribute loc of ff_wr_addrn1 : label is "slice_x41y9";
   attribute loc of ff_wr_addrn2 : label is "slice_x41y8";
   attribute loc of ff_wr_addrn3 : label is "slice_x41y8";

   -- --------------------------------------------------------------------

begin

   -- --------------------------------------------------------------------

   high <= '1';
   notlxclk <= not lxclk;

   -- --------------------------------------------------------------------
   -- FIFO write addresses for both phases of the clock

   wr_addrp_d <= wr_addrp + 1;

   wr_addrn_d <= not (rst & rst & rst & rst) and wr_addrp;

   ff_wr_addrp0 : fdc
     port map (d => wr_addrp_d(0), c => lxclk, clr => rst, q => wr_addrp(0));
   ff_wr_addrp1 : fdc
     port map (d => wr_addrp_d(1), c => lxclk, clr => rst, q => wr_addrp(1));
   ff_wr_addrp2 : fdc
     port map (d => wr_addrp_d(2), c => lxclk, clr => rst, q => wr_addrp(2));
   ff_wr_addrp3 : fdc
     port map (d => wr_addrp_d(3), c => lxclk, clr => rst, q => wr_addrp(3));

   ff_wr_addrn0 : fd
     port map (d => wr_addrn_d(0), c => notlxclk, q => wr_addrn(0));
   ff_wr_addrn1 : fd
     port map (d => wr_addrn_d(1), c => notlxclk, q => wr_addrn(1));
   ff_wr_addrn2 : fd
     port map (d => wr_addrn_d(2), c => notlxclk, q => wr_addrn(2));
   ff_wr_addrn3 : fd
     port map (d => wr_addrn_d(3), c => notlxclk, q => wr_addrn(3));

   -- --------------------------------------------------------------------
   -- The FIFO memories (LUTRAM)

   rp0 : ram16x1d
     port map (d => lxdata(0), we => high, wclk => lxclk,
               a0 => wr_addrp(0), a1 => wr_addrp(1),
               a2 => wr_addrp(2), a3 => wr_addrp(3),
               dpra0 => rd_addr(0), dpra1 => rd_addr(1),
               dpra2 => rd_addr(2), dpra3 => rd_addr(3),
               spo => open, dpo => int(0)
     );

   rp1 : ram16x1d
     port map (d => lxdata(1), we => high, wclk => lxclk,
               a0 => wr_addrp(0), a1 => wr_addrp(1),
               a2 => wr_addrp(2), a3 => wr_addrp(3),
               dpra0 => rd_addr(0), dpra1 => rd_addr(1),
               dpra2 => rd_addr(2), dpra3 => rd_addr(3),
               spo => open, dpo => int(1)
     );

   rp2 : ram16x1d
     port map (d => lxdata(2), we => high, wclk => lxclk,
               a0 => wr_addrp(0), a1 => wr_addrp(1),
               a2 => wr_addrp(2), a3 => wr_addrp(3),
               dpra0 => rd_addr(0), dpra1 => rd_addr(1),
               dpra2 => rd_addr(2), dpra3 => rd_addr(3),
               spo => open, dpo => int(2)
     );

   rp3 : ram16x1d
     port map (d => lxdata(3), we => high, wclk => lxclk,
               a0 => wr_addrp(0), a1 => wr_addrp(1),
               a2 => wr_addrp(2), a3 => wr_addrp(3),
               dpra0 => rd_addr(0), dpra1 => rd_addr(1),
               dpra2 => rd_addr(2), dpra3 => rd_addr(3),
               spo => open, dpo => int(3)
     );

   rn0 : ram16x1d
     port map (d => lxdata(0), we => high, wclk => notlxclk,
               a0 => wr_addrn(0), a1 => wr_addrn(1),
               a2 => wr_addrn(2), a3 => wr_addrn(3),
               dpra0 => rd_addr(0), dpra1 => rd_addr(1),
               dpra2 => rd_addr(2), dpra3 => rd_addr(3),
               spo => open, dpo => int(4)
     );

   rn1 : ram16x1d
     port map (d => lxdata(1), we => high, wclk => notlxclk,
               a0 => wr_addrn(0), a1 => wr_addrn(1),
               a2 => wr_addrn(2), a3 => wr_addrn(3),
               dpra0 => rd_addr(0), dpra1 => rd_addr(1),
               dpra2 => rd_addr(2), dpra3 => rd_addr(3),
               spo => open, dpo => int(5)
     );

   rn2 : ram16x1d
     port map (d => lxdata(2), we => high, wclk => notlxclk,
               a0 => wr_addrn(0), a1 => wr_addrn(1),
               a2 => wr_addrn(2), a3 => wr_addrn(3),
               dpra0 => rd_addr(0), dpra1 => rd_addr(1),
               dpra2 => rd_addr(2), dpra3 => rd_addr(3),
               spo => open, dpo => int(6)
     );

   rn3 : ram16x1d
     port map (d => lxdata(3), we => high, wclk => notlxclk,
               a0 => wr_addrn(0), a1 => wr_addrn(1),
               a2 => wr_addrn(2), a3 => wr_addrn(3),
               dpra0 => rd_addr(0), dpra1 => rd_addr(1),
               dpra2 => rd_addr(2), dpra3 => rd_addr(3),
               spo => open, dpo => int(7)
     );

   -- --------------------------------------------------------------------
   -- The FIFO readout state machine

   -- This assumes that the readout clock is no faster than the input
   -- clock.

   -- When the FIFO is not empty, a trigger is generated that enables
   -- the reading process. Once the FIFO is full, further transfers from
   -- the transmitting DSP are inhibited until it is completely empty
   -- again.

   -- Data is transferred out of the FIFO if the ready signal is asserted.
   -- data_en is driven high when data is available from the FIFO.
   -- If ready is negated on a particular clock edge, that means that
   -- the data for the previous clock period was not accepted by the
   -- downstream device.

   process (clock)
   begin
     if clock'event and clock = '1' then

       trigger_d <= (not lxacko_int) and (not set_lxacko);

       if rst = '1' then
         rd_addr <= X"0";
         data_en_int <= '0';
         fifo_state <= fifo_empty;
       else

         case fifo_state is

         when fifo_empty =>
           data_en_int <= '0';
           if trigger_d = '1' then
             fifo_state <= fifo_active;
             rd_addr <= rd_addr + 1;
             dataout <= int;
           end if;

         when fifo_active =>
           data_en_int <= ready;
           if data_en_int = '1' and ready = '1' then
             if rd_addr = X"F" then
               fifo_state <= fifo_final;
             end if;
             rd_addr <= rd_addr + 1;
             dataout <= int;
           end if;

         when fifo_final =>
           if data_en_int = '1' and ready = '1' then
             data_en_int <= '0';
             fifo_state <= fifo_empty;
           else
             data_en_int <= ready;
           end if;

         end case;

       end if;
     end if;
   end process;

   data_en <= data_en_int;

   -- --------------------------------------------------------------------
   -- LXACKO handshake with transmitting DSP

   -- This asynchronous process identifies the conditions in the above state
   -- machine under which the FIFO becomes empty. Note that this happens when
   -- the last byte has been transferred to the output register, even before
   -- the desination has accepted it.

   process (rst, fifo_state, data_en_int, ready, rd_addr, lxacko_int)
   begin
     if rst = '1'
     or (fifo_state = fifo_active
       and data_en_int = '1'
       and ready = '1'
       and rd_addr = X"F"
     )
     or lxacko_int = '1'
     then
       set_lxacko <= '1';
     else
       set_lxacko <= '0';
     end if;
   end process;

   -- This flip-flop is driven high synchronously by the system clock to
   -- enable transmission, but is immediately cleared asynchronously by
   -- the first clcok pulse from the transmitting DSP.

   ff_lxack : fdc
     port map
       ( d => set_lxacko
       , c => clock
       , clr => lxclk
       , q => lxacko_int
       );

   lxacko <= lxacko_int;

   -- --------------------------------------------------------------------

end;
============================================================================

Article: 120517
Subject: Re: LVPECL output skew
From: austin <austin@xilinx.com>
Date: Fri, 08 Jun 2007 07:32:04 -0700
Links: << >>  << T >>  << A >>
Bob,

Yes.

Austin

Article: 120518
Subject: Re: HELP with Asynch RAM
From: Duth <premduth@gmail.com>
Date: Fri, 08 Jun 2007 15:50:49 -0000
Links: << >>  << T >>  << A >>
On Jun 7, 10:40 pm, ARH <haghdo...@gmail.com> wrote:
> On Jun 8, 7:50 am, Frank <FrankT...@gmail.com> wrote:
>
>
>
> > PLEASE HELP:
>
> > In my design I have a bank of memory made up of 64 reg[31:0]'s. They
> > get synthesized into latches, and kill my timing because of a huge 64
> > X 32 sensitivity list.(See below).
>
> > How else can I synthesize a 64X32 block of Memory with Asynch Read,
> > Asynch Write, and where the Data_In shows up immediately on the
> > Data_Out?
>
> > Can I do it withXilinxCoreGen Modules?
>
> > //This part handles the read for the 64 32-bit registers which store
> > the data.
> > //The rd_address is 1-hot, 64-bit reg.
>
> > always @ (rd_address or q0 or q1 or q2 or q3 or q4 or q5 or q6 or q7
> >                      or q8 or q9 or qa or qb or qc or qd or qe or qf
> >                      or q10 or q11 or q12 or q13 or q14 or q15 or q16
> > or q17
> >                      or q18 or q19 or q1a or q1b or q1c or q1d or q1e
> > or q1f
> >                      or q20 or q21 or q22 or q23 or q24 or q25 or q26
> > or q27
> >                      or q28 or q29 or q2a or q2b or q2c or q2d or q2e
> > or q2f
> >                      or q30 or q31 or q32 or q33 or q34 or q35 or q36
> > or q37
> >                      or q38 or q39 or q3a or q3b or q3c or q3d or q3e
> > or q3f)
> >           begin
> >             case (1'b1) // synopsys full_case parallel_case
> >               rd_address[0]:    DO = q0;
> >               rd_address[1]:    DO = q1;
> >               rd_address[2]:    DO = q2;
> >               rd_address[3]:    DO = q3;
> >               rd_address[4]:    DO = q4;
> >               rd_address[5]:    DO = q5;
> >               rd_address[6]:    DO = q6;
> >               rd_address[7]:    DO = q7;
> >               rd_address[8]:    DO = q8;
> >               rd_address[9]:    DO = q9;
> >               rd_address[10]:    DO = qa;
> >               rd_address[11]:    DO = qb;
> >               rd_address[12]:    DO = qc;
> >               rd_address[13]:    DO = qd;
> >               rd_address[14]:    DO = qe;
> >               rd_address[15]:    DO = qf;
> >               rd_address[16]:    DO = q10;
> >               rd_address[17]:    DO = q11;
> >               rd_address[18]:    DO = q12;
> >               rd_address[19]:    DO = q13;
> >               rd_address[20]:    DO = q14;
> >               rd_address[21]:    DO = q15;
> >               rd_address[22]:    DO = q16;
> >               rd_address[23]:    DO = q17;
> >               rd_address[24]:    DO = q18;
> >               rd_address[25]:    DO = q19;
> >               rd_address[26]:    DO = q1a;
> >               rd_address[27]:    DO = q1b;
> >               rd_address[28]:    DO = q1c;
> >               rd_address[29]:    DO = q1d;
> >               rd_address[30]:    DO = q1e;
> >               rd_address[31]:    DO = q1f;
> >               rd_address[32]:    DO = q20;
> >               rd_address[33]:    DO = q21;
> >               rd_address[34]:    DO = q22;
> >               rd_address[35]:    DO = q23;
> >               rd_address[36]:    DO = q24;
> >               rd_address[37]:    DO = q25;
> >               rd_address[38]:    DO = q26;
> >               rd_address[39]:    DO = q27;
> >               rd_address[40]:    DO = q28;
> >               rd_address[41]:    DO = q29;
> >               rd_address[42]:    DO = q2a;
> >               rd_address[43]:    DO = q2b;
> >               rd_address[44]:    DO = q2c;
> >               rd_address[45]:    DO = q2d;
> >               rd_address[46]:    DO = q2e;
> >               rd_address[47]:    DO = q2f;
> >               rd_address[48]:    DO = q30;
> >               rd_address[49]:    DO = q31;
> >               rd_address[50]:    DO = q32;
> >               rd_address[51]:    DO = q33;
> >               rd_address[52]:    DO = q34;
> >               rd_address[53]:    DO = q35;
> >               rd_address[54]:    DO = q36;
> >               rd_address[55]:    DO = q37;
> >               rd_address[56]:    DO = q38;
> >               rd_address[57]:    DO = q39;
> >               rd_address[58]:    DO = q3a;
> >               rd_address[59]:    DO = q3b;
> >               rd_address[60]:    DO = q3c;
> >               rd_address[61]:    DO = q3d;
> >               rd_address[62]:    DO = q3e;
> >               rd_address[63]:    DO = q3f;
>
> Hi
>
> Two of the most over used and abused directives included in Verilog
> models are the directives "//synopsys full_case parallel_case". The
> popular myth that exists surrounding "full_case
> parallel_case" is that these Verilog directives always make designs
> smaller, faster and latch-free. This is false! Indeed, the "full_case
> parallel_case" switches frequently make designs larger and
> slower and can obscure the fact that latches have been inferred .
> These switches can also change the functionality of a design causing a
> mismatch between pre-synthesis and post-synthesissimulation, which if not discovered during gate-level simulations will
> cause an ASIC to be taped out with design problems.
>
> it is generally a bad coding practice to give the synthesis tool
> different information about the functionality of a design than is
> given to the simulator.
>
> Whenever either "full_case" or "parallel_case" directives are added to
> the Verilog source code, more information is potentially being given
> about the design to the synthesis tool than is being given to the
> simulator
>
> In general, do not use "full_case parallel_case" directives with any
> Verilog case statements.
>
>  ARH

Additionally, Xilinx Block Memory does not support Asynchronous read
and write modes. If you want to use Asynchronous modes, then you are
now automatically killing the timing of your design. If meeting timing
is your objective ideally you would want to map to Block Memory and in
order to do this, change to synchrnous timing. Asynchronous timing ,
especially when not careful of how you are using it, will always end
up in bad timing scores.

If you do want to do this in asynchronous mode, then the best you can
do is to code it to use distributed memory. If you want tools to infer
the memory, then please refer to the coding templates for the
synthesis tool you are using and you will achieve the correct
inference. As you have coded above, this is a latch based
implementation.

Thanks
Duth


Article: 120519
Subject: FPGA with ARM+CAN+USB+ethernet+ADC
From: Antti <Antti.Lukats@googlemail.com>
Date: Fri, 08 Jun 2007 08:51:06 -0700
Links: << >>  << T >>  << A >>
http://www.zylogic.com.cn/english/products04.htm

I wonder what that is?
it looks like the product Triscend never announced, but maybe its a
hoax,
still funny at least the spec are known now what Triscend was about to
announce
just before it was purchased by Xilinx

Antti


Article: 120520
Subject: Re: FPGA with ARM+CAN+USB+ethernet+ADC
From: Sean Durkin <news_jun07@durkin.de>
Date: Fri, 08 Jun 2007 18:03:01 +0200
Links: << >>  << T >>  << A >>
Antti wrote:
> http://www.zylogic.com.cn/english/products04.htm
> 
> I wonder what that is?
> it looks like the product Triscend never announced, but maybe its a
> hoax,
> still funny at least the spec are known now what Triscend was about to
> announce
> just before it was purchased by Xilinx
It doesn't just look like it: If you click on the product brief
(http://www.zylogic.com.cn/download/pdf/products01_2/A7VProductBrief.pdf),
it's from Triscend... with Triscend logo and everything.

cu,
Sean

-- 
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...

Article: 120521
Subject: Module LOCK possible in VHDL?
From: Pasacco <pasacco@gmail.com>
Date: Fri, 08 Jun 2007 09:31:10 -0700
Links: << >>  << T >>  << A >>
Dear

I want to get "actual clock frequency" of my design (in ISE tool).

Due to following problem, I am having trouble.

I implemented 20-port "crossbar network" module, in which number of I/
O pins is greater than number of FPGA I/O pins.

I synthesized and got 'estimated' clock frequency.

My goal is to "place and route" my design.

What I did was to " Put dummy module to each crossbar port "

Task of these dummy modules is
    - Get signals from the crossbar network
    - Register (or simple dummy arithmetic functions)
    - Forward the registered signals to the crossbar network.

In this way, I have only "clock, reset, result" pins in my TOP module.

Problem was that

Synthesizer optimizes, such that my dummy modules are 'almost' trimmed
away.

Accordingly, part of my crossbar network module is also removed.

It is very time-consuming to manually modify 20 dummy modules.

Question is that

- Can we make these dummy modules 'locked' in VHDL description, so
that the synthesizer will not try to optimize?

- Is there any other way to place/route my design, when number of I/O
pins is greater than number of FPGA pins?

Thank you for comment again.


Article: 120522
Subject: PBGA FPGA in hi-rel application
From: Daveb <dave.bryan@gmail.com>
Date: Fri, 08 Jun 2007 09:36:28 -0700
Links: << >>  << T >>  << A >>
Hi

I am involved in a high reliability application where the device we
want to use (Quicklogic EclipsePlus QL7160) is only available in a
208pin plastic PQFP (30mm sq) or 280pin plastic BGA (17mm sq). The
environment will subject the device to elevated temperature (~115deg)
and vibration (TBD). Has anyone any experience with using these types
of devices in such an environment & what kind of measures can be taken
to improve mechanical reliability ?

Also, does anyone have any general comments on Quicklogic devices and/
or support ?

Thanks
Dave


Article: 120523
Subject: Re: EDK Simulation Problem
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 08 Jun 2007 09:55:05 -0700
Links: << >>  << T >>  << A >>
motty wrote:
> I have upgraded to EDK 9.1 and am trying to generate the HDL
> simulation files.  I have successfully compiled both the ISE libraries
> and the EDK libraries.  They live in C:\xilinx_sim_libs and C:
> \xilinx_sim_libs\EDK respectively.  

Make sure that those directories contain the file "_info"
Maybe the compiled directory is really C:\xilinx_sim_libs\work

        -- Mike Treseler

Article: 120524
Subject: Re: FPGA with ARM+CAN+USB+ethernet+ADC
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Fri, 08 Jun 2007 10:12:49 -0700
Links: << >>  << T >>  << A >>
Antti wrote:
> http://www.zylogic.com.cn/english/products04.htm
> 
> I wonder what that is?
> it looks like the product Triscend never announced, but maybe its a
> hoax,
> still funny at least the spec are known now what Triscend was about to
> announce
> just before it was purchased by Xilinx
> 
> Antti
> 

Zylogic and Rochester were handling the end-of-life commitments
that were in place for the Triscend parts. I would be a bit
shocked if they would even take an order at this point unless
they still had some parts in stock.

Ed McGettigan
--
Xilinx Inc.



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search