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 140650

Article: 140650
Subject: No integer interpolation ...
From: secureasm@gmail.com
Date: Thu, 21 May 2009 01:33:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I have an I/Q OFDM analog signal on FIFO (like this is built is not
topic of the post). I read from this FIFO with NCO at frequency of
"64MHz / 7 (9.142857143 MHz)". The NCO clock is 64 MHz. The read
signal as 64MHz timing and pulse at 9.142857143 MHz. Now I have the
need to interpolate this signal x2 to obtain a 18.285714286 MHz of
sample rate.

How interpolate this signal with 64MHz of clock and 9.142857143 MHz of
sample time ?

I still can not dissociate the main clock from the sample
time ... :-| ...

Anyone have any idea ?

Kappa.

Article: 140651
Subject: Re: please recommend a soft processor for small image processing
From: CMOS <manusha1980@gmail.com>
Date: Thu, 21 May 2009 01:42:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 21, 9:35=A0am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On May 21, 7:30=A0am, CMOS <manusha1...@gmail.com> wrote:
>
>
>
> > On May 21, 12:17=A0am, Tommy Thorn <tommy.th...@gmail.com> wrote:
>
> > > On May 20, 11:05=A0am, CMOS <manusha1...@gmail.com> wrote:
>
> > > > hi all,
> > > > im planning to implement barcode scanning using a CMOS sensor. The
> > > > processing needs to happen inside a FPGA, so im evaluating my optio=
ns
> > > > in choosing a proper soft processor for the task. these are my
> > > > requirements.
>
> > > > 1) open source and need to be able to be used in commercial product=
s
> > > > 2) need to have good documentation and support tools (toolchain,
> > > > simulators, emulators)
> > > > 3) robust and stable
> > > > 4) need to use in an xilinx spartan 3 device with 400K gates.
>
> > > > i know about processors OpenRISC 1000, NIOS 2 and LEON 2, but not s=
ure
> > > > how good they are with regard to my requirements, specially the (2)=
,
> > > > (3) and (4) above. Please help.
>
> > > > in addition, i like to here about microblaze and its licensing fees
> > > > structure
>
> > > A few points:
> > > - Nios II and MicroBlaze aren't open source, but both are very good.
> > > - Is OpenRISC 1000 ok for commercial products?
> > > - I doubt LEON 2 (and maybe OpenRISC 1000) can fit in "400K gates"
>
> > > You could also consider YARI (http://yari.thorn.ws). It's a bit weak
> > > in the documentation department though but has great tools. The
> > > hardware debugger still work in progress, but YARI has excellent
> > > simulation support.
>
> > > Regards,
> > > Tommy
>
> > thanks tommy.
>
> > why do you think OpenRISC 1000 is not suitable for commercial
> > projects?
>
> > thanks.
>
> it doesnt fir s3-400 as a starter
>
> Antti

hi again,

i decided to go with LEON 2 processor, but i could not find a download
location for it. Can some one point me to a link?

thanks

Article: 140652
Subject: Re: Are all these claims in VHDL correct?
From: "Fredxx" <fredxx@spam.com>
Date: Thu, 21 May 2009 09:46:57 +0100
Links: << >>  << T >>  << A >>

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message 
news:ri0a15dqak38clq3j8uuvb2tl6lusob9lu@4ax.com...
>>
>>M4 : process(A1)
>>begin
>>   if A1 = '1' then
>>      X <= X1;
>>   end if;
>>end process;
>
> I agree that these two are identical in every meaningful way.
> "null;" really does nothing.
>
>>M5 : process(A1)
>>begin
>>   if A1 = '1' then
>>      X <= X1;
>>   else
>>      X <= X;
>>   end if;
>>end process;
>
> No, this is not the same.  In M5 but not in M4, when
> A1 transitions to a value that is not '1', signal X
> is written; there will be no value-change on X as a
> result, for sure, but there *is* a transaction on X
> and that could be detected, outside the process,
> with the 'transaction, 'active or 'quiet attributes.
>
> None of the processes M3 to M5 follow any conventional
> synthesis template.  If you had included X1 in the
> sensitivity list, they would all be perfectly good
> descriptions of a transparent latch.  If you had
> rewritten the condition as "if rising_edge(A1)" they
> would all be perfectly good descriptions of a register.
>

>>
>>M7 : process(CLK)
>>begin
>>   if CLK'event and CLK = '1' then
>>      if A1 = '1' then
>>         X <= X1;
>>      end if;
>>   end if;
>>end process;
>
> M6 and M7 are completely identical in behaviour, yes.
>
>>M8 : process(CLK)
>>begin
>>   if CLK'event and CLK = '1' then
>>      if A1 = '1' then
>>         X <= X1;
>>      else
>>         X <= X;
>>      end if;
>>   end if;
>>end process;
>
> Same discussion as for M5, above.
>

I'm missing the point here.  The sensitivity list for M4 and M5 only 
includes A1, so any change in X1 doesn't propagate through to X in either 
case.

Also, are you suggesting that an X <= X; would be seen as a transaction 
within a sensitivity list?

M9: process (X)
begin
    if X = '1' then
        Y <= Y1;
    end if;
end process;

where Y will take on the value of Y1, despite no change in X?



Article: 140653
Subject: Re: Are all these claims in VHDL correct?
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Thu, 21 May 2009 09:56:13 +0100
Links: << >>  << T >>  << A >>
On Thu, 21 May 2009 09:46:57 +0100, "Fredxx" wrote:

>> None of the processes M3 to M5 follow any conventional
>> synthesis template.  If you had included X1 in the
>> sensitivity list, they would all be perfectly good
>> descriptions of a transparent latch.  If you had
>> rewritten the condition as "if rising_edge(A1)" they
>> would all be perfectly good descriptions of a register.
[...]
>I'm missing the point here.  The sensitivity list for M4 and M5 only 
>includes A1, so any change in X1 doesn't propagate through to X in either 

Right.  So the description is not a piece of synthesisable
hardware; it's neither a latch, nor a register, nor a 
combinational function.  I agree that the externally 
observable simulation behaviour would be the same for
all those examples, apart from the 'transaction thing
I mentioned.  But it's not very useful.

>Also, are you suggesting that an X <= X; would be seen as a transaction 
>within a sensitivity list?

No.  Be careful about the terminology; sensitivity lists see
EVENTS, i.e. value-changes, on a signal; there is of course
no such event as a result of X<=X.  However, there is a
TRANSACTION, an attempt to update X.  You can't ordinarily
see transactions in VHDL, but you can detect them using
the built-in attributes I mentioned.

>M9: process (X)
>begin
>    if X = '1' then
>        Y <= Y1;
>    end if;
>end process;
>
>where Y will take on the value of Y1, despite no change in X?

Sorry, I don't see what you're asking here.  If there's no change
in X's value then the process won't run and Y won't update.
In a real hardware transparent latch, you DO expect Y to follow
the input Y1 if the enable X is asserted; you can easily get this
by including both X and Y1 in the sensitivity list, and that gives
you a good synthesisable description of a transparent latch.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 140654
Subject: Re: Are all these claims in VHDL correct?
From: "Fredxx" <fredxx@spam.com>
Date: Thu, 21 May 2009 10:09:26 +0100
Links: << >>  << T >>  << A >>

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message 
news:g85a15lp0jd5kap4u0n5rlbq82k2l3mbh1@4ax.com...
> On Thu, 21 May 2009 09:46:57 +0100, "Fredxx" wrote:
>
>>> None of the processes M3 to M5 follow any conventional
>>> synthesis template.  If you had included X1 in the
>>> sensitivity list, they would all be perfectly good
>>> descriptions of a transparent latch.  If you had
>>> rewritten the condition as "if rising_edge(A1)" they
>>> would all be perfectly good descriptions of a register.
> [...]
>>I'm missing the point here.  The sensitivity list for M4 and M5 only
>>includes A1, so any change in X1 doesn't propagate through to X in either
>
> Right.  So the description is not a piece of synthesisable
> hardware; it's neither a latch, nor a register, nor a
> combinational function.  I agree that the externally
> observable simulation behaviour would be the same for
> all those examples, apart from the 'transaction thing
> I mentioned.  But it's not very useful.
>
>>Also, are you suggesting that an X <= X; would be seen as a transaction
>>within a sensitivity list?
>
> No.  Be careful about the terminology; sensitivity lists see
> EVENTS, i.e. value-changes, on a signal; there is of course
> no such event as a result of X<=X.  However, there is a
> TRANSACTION, an attempt to update X.  You can't ordinarily
> see transactions in VHDL, but you can detect them using
> the built-in attributes I mentioned.
>

It is synthsisable but perhaps not tgive the intended result.  In essence an 
event on A1 and A1 = 1, would cause the value X1 to be latched into X.  In 
both cases?

>>M9: process (X)
>>begin
>>    if X = '1' then
>>        Y <= Y1;
>>    end if;
>>end process;
>>
>>where Y will take on the value of Y1, despite no change in X?
>
> Sorry, I don't see what you're asking here.  If there's no change
> in X's value then the process won't run and Y won't update.
> In a real hardware transparent latch, you DO expect Y to follow
> the input Y1 if the enable X is asserted; you can easily get this
> by including both X and Y1 in the sensitivity list, and that gives
> you a good synthesisable description of a transparent latch.


That was my point, how would a transaction on X be "seen"? I thought VHDL 
was all about events.



Article: 140655
Subject: Re: Sigasi Public Beta: future of VHDL design
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Thu, 21 May 2009 11:22:24 +0200
Links: << >>  << T >>  << A >>
colin_toogood@yahoo.com wrote:
> I created an account and downloaded it. Then I noticed the one month
> license and no pricing. Perhaps you might post again when you have
> decided whether I can afford it at which point I will try it. Your
> website promises many of the things I've always wanted from an editor.

The beta program conditions are explained here:

    http://www.sigasi.com/betaconditions

Jan

Article: 140656
Subject: Re: please recommend a soft processor for small image processing
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Thu, 21 May 2009 02:30:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 21, 11:42=A0am, CMOS <manusha1...@gmail.com> wrote:
> On May 21, 9:35=A0am, "Antti.Luk...@googlemail.com"
>
>
>
> <Antti.Luk...@googlemail.com> wrote:
> > On May 21, 7:30=A0am, CMOS <manusha1...@gmail.com> wrote:
>
> > > On May 21, 12:17=A0am, Tommy Thorn <tommy.th...@gmail.com> wrote:
>
> > > > On May 20, 11:05=A0am, CMOS <manusha1...@gmail.com> wrote:
>
> > > > > hi all,
> > > > > im planning to implement barcode scanning using a CMOS sensor. Th=
e
> > > > > processing needs to happen inside a FPGA, so im evaluating my opt=
ions
> > > > > in choosing a proper soft processor for the task. these are my
> > > > > requirements.
>
> > > > > 1) open source and need to be able to be used in commercial produ=
cts
> > > > > 2) need to have good documentation and support tools (toolchain,
> > > > > simulators, emulators)
> > > > > 3) robust and stable
> > > > > 4) need to use in an xilinx spartan 3 device with 400K gates.
>
> > > > > i know about processors OpenRISC 1000, NIOS 2 and LEON 2, but not=
 sure
> > > > > how good they are with regard to my requirements, specially the (=
2),
> > > > > (3) and (4) above. Please help.
>
> > > > > in addition, i like to here about microblaze and its licensing fe=
es
> > > > > structure
>
> > > > A few points:
> > > > - Nios II and MicroBlaze aren't open source, but both are very good=
.
> > > > - Is OpenRISC 1000 ok for commercial products?
> > > > - I doubt LEON 2 (and maybe OpenRISC 1000) can fit in "400K gates"
>
> > > > You could also consider YARI (http://yari.thorn.ws). It's a bit wea=
k
> > > > in the documentation department though but has great tools. The
> > > > hardware debugger still work in progress, but YARI has excellent
> > > > simulation support.
>
> > > > Regards,
> > > > Tommy
>
> > > thanks tommy.
>
> > > why do you think OpenRISC 1000 is not suitable for commercial
> > > projects?
>
> > > thanks.
>
> > it doesnt fir s3-400 as a starter
>
> > Antti
>
> hi again,
>
> i decided to go with LEON 2 processor, but i could not find a download
> location for it. Can some one point me to a link?
>
> thanks

LEON-2 is deprecated, if using LEON should take 3

and: while LEON just may fit s3-400 (I have done that) it leave no
resources left for you
so it is not an option for s3-400


Antti


Article: 140657
Subject: 90 degree phase shifted clock for RGMII
From: aitezaz.abd@gmail.com
Date: Thu, 21 May 2009 02:36:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi All,
I need a clock of 2.5 MHz and its 90 degree phase shifted version to
work with 10Mbps ethernet MAC on 1G/100M/10M PHY. I have a clock of
125 MHz and to comply with the DCM requirements, I have derived a
clock of 40 MHz from 125 MHz using DCM. Now, I have derived a clock of
2.5 MHz for RGMII interface (because PHY is RGMII based) from 40 MHz
using counters. For this, I have produced the 40 MHz true and 90
degree phase shifted clock and then derived 2.5 MHz clocks from both
of the versions (to get clock with 0 degree and 90 degree). But, as I
suspect, it is not the correct solution as 90 degree for 40 MHz has a
different time span than that of 2.5 MHz. I want to know how can I
produce 90 degree phase shifted 2.5 MHz clock from 125 MHz clock.
Following is the code that i have used

 IBUF ibufg_gtx_clk (.I(gtx_clk),           .O(gtx_clk_ibufg));


   dcm_40M_out					dcm_40M_out_inst(
   								.CLKIN_IN(gtx_clk_ibufg),
                  			.RST_IN(reset),
                  			.CLKFX_OUT(gtx_clk_40M),
                  			.CLK0_OUT(),
                  			.LOCKED_OUT()
                  			);

	dcm_40M_90					dcm_40M_90_inst(
									.CLKIN_IN(gtx_clk_40M_bufg),
                  			.RST_IN(reset),
                  			.CLK0_OUT(gtx_clk0_out),
                  			.CLK90_OUT(gtx_clk90_out),
                  			.LOCKED_OUT()
                  			);

   BUFGMUX BUFGMUX_TXCLK_25 (
                           .O(gtx_clk_40M_bufg),
                           .I0(gtx_clk_40M),
                           .I1(),  // not used
                           .S(1'b0)
                           );


   assign	cntr_00deg_sum_out = cntr_00deg + 1;
   assign	cntr_90deg_sum_out = cntr_90deg + 1;

   always@(posedge gtx_clk0_out)
   begin
   	if(reset)		cntr_00deg <= 0;
   	else				cntr_00deg <= cntr_00deg_sum_out;
	end

	always@(posedge gtx_clk90_out)
   begin
   	if(reset)		cntr_90deg <= 0;
   	else				cntr_90deg <= cntr_90deg_sum_out;
	end


    BUFGMUX BUFGMUX_TXCLK (
                           .O(tx_rgmii_clk_int),
                           .I0(cntr_00deg[4]),
                           .I1(cntr_90deg[4]),  // not used
                           .S(1'b0)
                           );

   BUFGMUX BUFGMUX_TXCLK90 (
                            .O(tx_rgmii_clk90_int),
                            .I1(cntr_00deg[4]),  // not used
                            .I0(cntr_90deg[4]),
                            .S(1'b0)
                            );


Article: 140658
Subject: Re: Sigasi Public Beta: future of VHDL design
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 21 May 2009 10:37:10 +0100
Links: << >>  << T >>  << A >>
<colin_toogood@yahoo.com> wrote in message 
news:ab4b2e35-883a-4ae3-bd3d-e7e8bddae345@l32g2000vba.googlegroups.com...
>I created an account and downloaded it. Then I noticed the one month
> license and no pricing. Perhaps you might post again when you have
> decided whether I can afford it at which point I will try it. Your
> website promises many of the things I've always wanted from an editor.
> Colin

Colin,

If you email them they'll give you an outline of what they're thinking
about pricing wise.

I think they should publish this.


Niall 



Article: 140659
Subject: Re: ISIM and CONV_INTEGER warnings
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Thu, 21 May 2009 04:56:50 -0500
Links: << >>  << T >>  << A >>
"HT-Lab" <hans64@ht-lab.com> wrote in message 
news:747Rl.100828$mS6.72054@newsfe27.ams2...
> It is quite easy to get gazillions of these messages in VHDL, for example 
> before a reset is asserted or a tri-state bus feeding into an adder (as 
> was in my case). These warnings prevents you from seeing any other 
> messages. It also seriously hampers your simulation performance since 
> writing to the transcript window (at least in Modelsim) is a real 
> performance hog.

I sometimes forget just how little I know, and appreciate your patient 
response.



Article: 140660
Subject: Re: please recommend a soft processor for small image processing
From: ales.gorkic@gmail.com
Date: Thu, 21 May 2009 03:57:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 21, 10:42=A0am, CMOS <manusha1...@gmail.com> wrote:
> On May 21, 9:35=A0am, "Antti.Luk...@googlemail.com"
>
>
>
> <Antti.Luk...@googlemail.com> wrote:
> > On May 21, 7:30=A0am, CMOS <manusha1...@gmail.com> wrote:
>
> > > On May 21, 12:17=A0am, Tommy Thorn <tommy.th...@gmail.com> wrote:
>
> > > > On May 20, 11:05=A0am, CMOS <manusha1...@gmail.com> wrote:
>
> > > > > hi all,
> > > > > im planning to implement barcode scanning using a CMOS sensor. Th=
e
> > > > > processing needs to happen inside a FPGA, so im evaluating my opt=
ions
> > > > > in choosing a proper soft processor for the task. these are my
> > > > > requirements.
>
> > > > > 1) open source and need to be able to be used in commercial produ=
cts
> > > > > 2) need to have good documentation and support tools (toolchain,
> > > > > simulators, emulators)
> > > > > 3) robust and stable
> > > > > 4) need to use in an xilinx spartan 3 device with 400K gates.
>
> > > > > i know about processors OpenRISC 1000, NIOS 2 and LEON 2, but not=
 sure
> > > > > how good they are with regard to my requirements, specially the (=
2),
> > > > > (3) and (4) above. Please help.
>
> > > > > in addition, i like to here about microblaze and its licensing fe=
es
> > > > > structure
>
> > > > A few points:
> > > > - Nios II and MicroBlaze aren't open source, but both are very good=
.
> > > > - Is OpenRISC 1000 ok for commercial products?
> > > > - I doubt LEON 2 (and maybe OpenRISC 1000) can fit in "400K gates"
>
> > > > You could also consider YARI (http://yari.thorn.ws). It's a bit wea=
k
> > > > in the documentation department though but has great tools. The
> > > > hardware debugger still work in progress, but YARI has excellent
> > > > simulation support.
>
> > > > Regards,
> > > > Tommy
>
> > > thanks tommy.
>
> > > why do you think OpenRISC 1000 is not suitable for commercial
> > > projects?
>
> > > thanks.
>
> > it doesnt fir s3-400 as a starter
>
> > Antti
>
> hi again,
>
> i decided to go with LEON 2 processor, but i could not find a download
> location for it. Can some one point me to a link?
>
> thanks

MicroBlaze is nice and easy to use, but with s3-400 you won't have
much space left. Since the processor could not digest data in real
time, you probably need a frame buffer also, so bigger FPGA is
probably inevitable.
You might consider taking this imaging development kit for a start:
www.optomotive.si


Cheers,

Ales

Article: 140661
Subject: Re: ISIM and CONV_INTEGER warnings
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 21 May 2009 12:09:25 +0100
Links: << >>  << T >>  << A >>
On Wed, 20 May 2009 10:32:06 +0100, "HT-Lab" <hans64@ht-lab.com> wrote:

>Does anybody know how to disable the CONV_INTEGER warnings in ISIM (11.1)?
>
>at 3000290500 ps(1), Instance /cpu_top_tb/U_12/ : Warning: CONV_INTEGER: 
>There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, and it has been 
>converted to 0.
>at 3000365500 ps(1), Instance /cpu_top_tb/U_12/ : Warning: CONV_INTEGER: 
>There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, and it has been 
>converted to 0.

I don't see these errors from CONV_INTEGER because I use numeric_std instead,
but it looks like the same situation.

My response is to identify the worst culprits and apply "to_01" functions in
appropriate places. I usually live with the remainder which in my projects are
confined to the first few hundred ns after reset as valid signals propagate
through the pipelines.

This way (a) I don't have to globally suppress the warning, so unexpected
consequences of later changes can be caught as early as possible. 
(b) I am aware of where the "problem" is occurring and happy that it is only the
result of expected (and allowed) circumstances as above.

It sounds like a tedious task but you may be surprised by how few "to_01"
functions are required; probably half a dozen on the designs I have experience
of.

- Brian

Article: 140662
Subject: Re: Are all these claims in VHDL correct?
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Thu, 21 May 2009 12:21:06 +0100
Links: << >>  << T >>  << A >>
On Thu, 21 May 2009 10:09:26 +0100, "Fredxx" wrote:

[regarding this example]

  M4 : process(A1)
  begin
     if A1 = '1' then
        X <= X1;
     end if;
  end process;

>It is synthsisable but perhaps not tgive the intended result.  
>In essence an event on A1 and A1 = 1, would cause the value 
>X1 to be latched into X.

I'm confused.  I already explained, with justification,
why it's not correctly synthesisable, and then you tell 
me it is...

Here's why that is BAD code for synthesis:
- The description, as you say, implies latching only on the
  rising edge of A1.  Like a D flop.
- But there is no "if A1'event" or "if rising_edge(A1)" in
  the process.  So it doesn't match the standard clocked
  synthesis template.

In the synth tool I tried just now (Mentor Precision)
I got a warning about precisely this, telling me that
there might be synthesis/simulation mismatches (there will).
And it created a transparent latch, because - as usual -
for any non-clocked process, synthesis will assume a 
complete sensitivity list.  Personally I would prefer it
if synthesis tools were to reject the code as an error,
but that's not what happens; instead you get hardware 
whose behaviour doesn't match the simulation.  I'm fairly
sure that almost all mainstream synthesis tools behave
in a similar way on this example, but I can't be bothered
trying them all because it's code that should not be
synthesised.

>In both cases?

I already stated, correctly and with explanation, that 
Weng's processes M4 and M5 have identical behaviour
in simulation.  Both of them are inappropriate for
synthesis.

>how would a transaction on X be "seen"? I thought VHDL 
>was all about events.

As I already pointed out, you can sense transactions in
simulation by using the 'transaction, 'active and 'quiet
built-in attributes.  VHDL transactions have no use
in synthesis.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 140663
Subject: Re: Can we expect ISE Gui and makefile to produce identical bit files?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 21 May 2009 12:33:02 +0100
Links: << >>  << T >>  << A >>
On Wed, 20 May 2009 19:16:41 -0700 (PDT), andrew.newsgroup@gmail.com wrote:

>Hi,
>We are switching to a makefile to build our Xilinx FPGA bit files. Can
>we expect to get an identical bit file (except for date/time in the
>bitfile header) if we build through the ISE gui vs building via the
>command line?
>
>What we have found is that the output ngd file from the ngdbuild
>process (Translate) is not the same in both cases. The file size
>differs by 100 bytes, and the resulting bitfiles end up being very
>different. Can we expect the ngd file to be identical?
>
>We use synplicity to synthesize the design, which creates an edif
>netlist. The edif netlist going into the ISE flow and makefile flow
>are identical.
>

You'd like to think so, and if ALL the flags and options are identical, I
believe it should be the case. But achieving that may not be trivial.

Try running Translate from the command line with the exact command line given in
the ".cmdlog" file - including the "-intstyle ISE" flag and see if that gives
the same result as the GUI flow.

The 'project.ise' can supposedly be exported as a script, reading which should
help discover the missing options. These should then be applicable through the
command line.

However...

One worrying datapoint is Xilinx's own PCIe interface project for the V5 ML506
board, where the advice given is to use the implementation shell script rather
than attempting to build through the GUI; with no further explanation.

Indeed an apparently successful run through the GUI tools produces a
non-functional bitfile! I have not had time to explore deeply enough to 
find out why.

- Brian


Article: 140664
Subject: Re: Port assignment question
From: hassen.karray@gmail.com
Date: Thu, 21 May 2009 04:53:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 20 mai, 23:19, Nicolas Matringe <nicolas.matri...@fre.fre> wrote:
> hassen.kar...@gmail.com a =E9crit :
>
> > put a clock in your process : process(clk) but don't use it inernally,
> > it is just a syntax issue .
>
> WHAT ?!
> This is pure nonsense. Put your input signals in the sensitivity list :
> process (bus2, pin_11, pin_22)
>
> Nicolas

Dear Nicolas,

You can put input signals in your sensitivity list ! you can also put
your clock ...

As long he'll not use any rising or falling edges , it will be
synthesized the same way.

Now, Talking about " pure nonsense " , assigning the same signal twice
or more in the very same single process is theorically "pure nonsence"
too, since only one single driver will be allowed finally ;)

Either ways here, Synthsis tool will handle the design the same way
and will finally put direct assignments , no clock, no input signals
sensitive FF or latches ...

We are talking here about a kind of tip to do things rapidly ... i
agree with you that it is not academic though !

I have seen people with deep knowledge about synthesis and
implementation tools doing awesome things with VHDL, they code in a "
pure nonsence " style and get things working very quickly ... i
somehow like that even though it doesn't garantee portability ...

Best Regards,
Hassen KARRAY.


Article: 140665
Subject: Re: Are all these claims in VHDL correct?
From: Andy <jonesandy@comcast.net>
Date: Thu, 21 May 2009 06:49:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
I think we can summarize...

M1 and M2 will synthesize to identical combinatorial circuits. There
may be warnings about synthesis/simulations mis-matches if the
sensitivity lists are not complete.

M3, M4 and M5 will synthesize to identical combinatorial circuits,
with a warning on the incomplete sensitivity list.

M6 and M7 will synthesize to identical sequential circuits (D-flop
with clk enable). M8 will synthesize to a sequential circuit with
identical behavior (on a clock cycle basis) to that of M6 and M7, but
the synthesis tool may try to build a feedback mux instead of using
the built-in clk enable on the register. Different synthesis tools may
handle this differently.

It should be noted that if X were a port of mode OUT (or an alias
thereof), then the processes that attempt to read X (M5 & M8) would
not synthesize at all.

It should also be noted that of M1 and M2, M1 is preferable for one
significant reason: The default assignemnt to X up front makes it very
easy to verify that M1 will not result in a latch. It is more
difficult to verify that M2 will not result in a latch.

Andy

Article: 140666
Subject: Re: Port assignment question
From: Andy <jonesandy@comcast.net>
Date: Thu, 21 May 2009 07:15:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hassen,

Putting clock (and only clock) in the sensitivity list of a non-
clocked process is pure nonsense when you (attempt to) simulate it.

Recommending practices that categorically exclude simulation is pure
nonsense.

Andy

Article: 140667
Subject: Nibz VHDL Processor (Version G-spot)
From: jacko <jackokring@gmail.com>
Date: Thu, 21 May 2009 07:26:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi

72MHz it's hot! But cool. Lower un-necessary D_O pin state transitions
etc. Estimated 17 MIPS on 8 bit bus.

http://nibz.goglecode.com for download. Any improvements for speed or
power efficiency while keeping low area welcome.

BSD license, or 1 core (instruction stream) per chip (packaged
semiconductor or logic substrate) license.

44% of MAX II 1270 C5 (527 LEs in speed technology)

8 Bit data bus, and ALU now 8 bit pipelined, as 16 bit is same space
with no pipeline. ALU completion in following instruction fetch. 16
bit ISA. Stack style of programming.

Clock possibly higher as critical path driven from latched value
register.

Interleave RW for full cycle RW_O = '0' on both hi and low byte (quite
a large part of the design).

A full Moore machine, all outputs driven by registers. In full custom
this allows the large IO pad drivers to provide the feedback. Much of
the instruction decode is pipelined due to most significant decoded
bits are in the low byte.

Should be suitable for interfacing to BRAM (with common address on
read and write) or external SRAM.

cheers jacko

p.s. much of the pipelining is only possible with a low logic area
because of the half width data bus dual fetching of data. Even though
the design is big endian, the fetches and stores are done little
endian for the usual carry propergation reasons, and for instruction
decode efficiency.

Article: 140668
Subject: Re: Can we expect ISE Gui and makefile to produce identical bit
From: phil hays <philhays@dont.spam>
Date: Thu, 21 May 2009 14:30:21 GMT
Links: << >>  << T >>  << A >>
David Antliff wrote:

>  - we are using Xilinx 10.1 service pack 3 on Windows XP, and a recent
> installation of Cygwin.
>  - we are trying to incorporate Xilinx into our automated build system
> - so we are running the Xilinx command-line applications from a GNU
> Makefile invoked from a Cygwin bash shell.
>  - we want to avoid the project .ise file completely as this seems to
> change every time anyone opens it - this makes build tracking difficult
> and therefore the .ise file is unsuitable as an input to our automated
> build process.

As the .ise working file changes every run, and is binary to boot, it can 
not be an input into a stable and maintainable build process. So the 
solution I've used when using gnu make under Cygwin is to delete the 
whole result directory (bld) at the start of the build. There are other 
files in the result directory (and sub-directories under it) that can 
influence the build, and the only way that I'm aware of to get a 
consistent result is to start with a fresh directory.

Directory tree I've used looks something like this (Ascii art follows, 
view with fixed pitch font)

     Project
        |
    -----------
    |         |
   src       bld
    |
  -------
  |     |
 hdl  cores

The makefile exists in .src, and if any source file has changed it does 
this:
	rm -rf ../bld
	mkdir ../bld

> We would like the output from ISE to exactly match the output from the 
> commandline, and if this is not possible then we'd like to know why the
> two output files differ.

One option for doing this would be to have the make file call a Project 
Navigator Tcl script (using xtclsh). This script would create a 
fresh .ise file every run, and could also be used to run from the GUI. I 
posted a script for this sometime ago, and will update it if desired.


> HOWEVER
> 
> Instead of "Reading in constraint information from 'Constraints/
> FPGA_DAC16v2.ucf'..." we see this instead:
> 
> ...
> Applying constraints in "d:/DAC_16v2/FPGA_DAC16V2/PAR/FPGA_DAC16V2/
> Constraints/FPGA_DAC16V2.ucf" to the design... ...
> 
> This is not what the ISE flow said it was doing. It read the UCF file
> but it certainly didn't say it was applying the constraints!

This is because the ISE flow seems to read the UCF file into a data base 
first, and then applies the constraints later. 


> 4. why does the .ise Project file continually change? Even running
> 'ngdbuild -ise FPGA_DAC16V2.ise -h' to display the program's HELP text
> causes the .ise file to change! Why? This makes it very difficult to
> manage in a Source Control tool because it's continually changing
> without a clear reason.

The .ise file has lots of date and time information. The solution to this 
is to think of the .ise file as a working file, rather than a project 
file and to delete it at the start of any build script. There are other 
working files, such as the constraint data base (which lives in a 
subdirectory of bld), and it is safest to delete them all by removing the 
working directory. Even the command lines tools can create and use a .ise 
file for their own use.

To difference the .bit files, the header needs to be ignored. To make 
this automatic, I've written a little difference utility using Tcl. Would 
this be of interest?

(phil_hays at eeei.gro (fix the order for email)

Article: 140669
Subject: Re: No integer interpolation ...
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 21 May 2009 10:34:09 -0400
Links: << >>  << T >>  << A >>
There are basically two ways. One is to change your main clock to a multiple 
of both frequencies, e.g. to 128 MHz. Another way is to run all your 
internal processing in burst mode at whatever frequency which is fast enough 
and then to bring the output to the real time though a single async fifo.


/Mikhail



<secureasm@gmail.com> wrote in message 
news:c5338a45-d4c4-404e-9a55-2df38e5ba843@g19g2000vbi.googlegroups.com...
> Hi,
>
> I have an I/Q OFDM analog signal on FIFO (like this is built is not
> topic of the post). I read from this FIFO with NCO at frequency of
> "64MHz / 7 (9.142857143 MHz)". The NCO clock is 64 MHz. The read
> signal as 64MHz timing and pulse at 9.142857143 MHz. Now I have the
> need to interpolate this signal x2 to obtain a 18.285714286 MHz of
> sample rate.
>
> How interpolate this signal with 64MHz of clock and 9.142857143 MHz of
> sample time ?
>
> I still can not dissociate the main clock from the sample
> time ... :-| ...
>
> Anyone have any idea ?
>
> Kappa. 



Article: 140670
Subject: Re: Muli-Cycle Path Constrains in RTL
From: Andy <jonesandy@comcast.net>
Date: Thu, 21 May 2009 07:47:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 20, 11:24=A0am, Mike Treseler <mtrese...@gmail.com> wrote:
>
> No, that is a synthesis timing constraint.
>
> I can eliminate the requirement in my
> code by adding a synchronous handshake
> or pipeline.
>
> =A0 =A0 -- Mike Treseler

Not sure I understand...

MCP constraints relax timing on long combinatorial paths that need not
complete in a single clock cycle (due to clock enables, etc). The only
way to avoid them is to speed up the paths, or break them up into
sequential sub-paths that will each complete in one clock cycle
(pipeline). Seems like a lot of hard work to keep the synthesis/P&R
tool from working harder/longer than it needs to (and probably
failing) in the first place.

The problem with MCP constraints is that it is very difficult to
verify that they are properly applied, except with extensive post-
route, full timing simulations. It is also easy to forget non-nominal
situations in which those paths may not actually be MCPs. Users often
fall into the trap of assuming that every input to every register that
is only clock enabled once every N clocks necessarily has an MCP of
N.

There are reportedly tools available (expensive) that will perform
formal analysis and either create accurate MCP constraints, or verify
existing ones without simulation.

If you know your MCP is correctly specified (you are relaxing
constraints on the exact signals/paths you thought you were), you can
use assertions in the RTL to verify them by ensuring that changes to
the value of specific signals do not occur except as expected by the
MCP constraint. If these assertions could be standardized (use
standardized functions, etc), then perhaps synthesis could make use of
them to create associated MCP constraints automatically.

I'm thinking of a function something like: is_stable(input_name, N,
clk_name, enable_name) returns boolean; (sorry this is in VHDL) that
would verify the MC behavior of the signal during RTL simulation.

Andy

Article: 140671
Subject: Re: No integer interpolation ...
From: secureasm@gmail.com
Date: Thu, 21 May 2009 08:18:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Mikhail,

thanks for your replay.

> There are basically two ways. One is to change your main clock to a multiple
> of both frequencies, e.g. to 128 MHz.

This route is not viable, I  choose the second solution.

> Another way is to run all your internal processing in burst mode at whatever frequency which is fast enough
> and then to bring the output to the real time though a single async fifo.

I actually write to the FIFO in burst mode and read at the sample
rate. At this point I should interpolate by two.

According to your idea, if I understand correctly, write to the FIFO
in burst mode but before write I apply the interpolator filter x2 and
read from fifo at x2 sample rate.

I have understood ?

But how interpolate x2 before write to FIFO ?

Kappa.

Article: 140672
Subject: Re: DCM Jitter
From: austin <austin@xilinx.com>
Date: Thu, 21 May 2009 08:25:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
Syms,

The DCM never attenuates jitter.  It can not be accidentally 'correct'
all the time (zig for every zag...).  It is a delay line.  What goes
in, is guaranteed to come out.

The DCM only changes one tap at a time (based on the FACTORY_JF
setting, it is that number times 6 or 36 -- depending on family --
input clocks for one tap change).  The FACTORY_JF is completely miss-
leading, as the intent was to allow the DCM to tolerate input jitter,
but correcting often, or not so often, does nothing to tolerate input
jitter.  And since it only updates one tap, the FACTORY_JF also does
nothing to increase or decrease the output jitter.  The only time we
recommended changing the FACTORY_JF setting was for the Vccaux dV/dt '
issue' on Virtex II (subsequently fixed in all later devices).

I suspect that if the output is a PWM signal, that jitter is no issue
whatsoever, as the PWM signal is a signal that has potentially 100%
"jitter" just to do what it is supposed to be doing.  I am not sure
what the poster really is concerned about.

There is a hidden setting to freeze the DCM updates of the taps, but
it really isn't of any use, other than for testing (does the added tap
switch jitter break the design?  If so, you are so close to your
timing margin -- no slack -- that you really need to find and
constrain the paths where the device has insufficient slack).

Austin

Article: 140673
Subject: Re: No integer interpolation ...
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 21 May 2009 11:34:00 -0400
Links: << >>  << T >>  << A >>
<secureasm@gmail.com> wrote in message 
news:174612d0-4248-4a61-beb5-81436c807109@3g2000yqk.googlegroups.com...
>
> According to your idea, if I understand correctly, write to the FIFO
> in burst mode but before write I apply the interpolator filter x2 and
> read from fifo at x2 sample rate.
>
> But how interpolate x2 before write to FIFO ?

From the data stream point of view an interpolate by 2  filter is simply a 
device producing two output sample for each input sample. It can be run in 
burst mode at any frequency which is more or equal 2x your input sample 
frequency. If you are using Xilinx take a look at their FIR IP cores.


/Mikhail 



Article: 140674
Subject: Re: Nibz VHDL Processor (Version G-spot)
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Thu, 21 May 2009 08:45:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 21, 5:26=A0pm, jacko <jackokr...@gmail.com> wrote:
> Hi
>
> 72MHz it's hot! But cool. Lower un-necessary D_O pin state transitions
> etc. Estimated 17 MIPS on 8 bit bus.
>
> http://nibz.goglecode.comfor download. Any improvements for speed or
> power efficiency while keeping low area welcome.
>
> BSD license, or 1 core (instruction stream) per chip (packaged
> semiconductor or logic substrate) license.
>
> 44% of MAX II 1270 C5 (527 LEs in speed technology)
>
> 8 Bit data bus, and ALU now 8 bit pipelined, as 16 bit is same space
> with no pipeline. ALU completion in following instruction fetch. 16
> bit ISA. Stack style of programming.
>
> Clock possibly higher as critical path driven from latched value
> register.
>
> Interleave RW for full cycle RW_O =3D '0' on both hi and low byte (quite
> a large part of the design).
>
> A full Moore machine, all outputs driven by registers. In full custom
> this allows the large IO pad drivers to provide the feedback. Much of
> the instruction decode is pipelined due to most significant decoded
> bits are in the low byte.
>
> Should be suitable for interfacing to BRAM (with common address on
> read and write) or external SRAM.
>
> cheers jacko
>
> p.s. much of the pipelining is only possible with a low logic area
> because of the half width data bus dual fetching of data. Even though
> the design is big endian, the fetches and stores are done little
> endian for the usual carry propergation reasons, and for instruction
> decode efficiency.

goglecode?

G-spot?
have you ever found it?

Antti



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