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 153350

Article: 153350
Subject: Re: A smallish starter Kit for led control
From: LM <sala.nimi@mail.com>
Date: Sat, 4 Feb 2012 15:43:57 -0800 (PST)
Links: << >>  << T >>  << A >>
On 4 helmi, 11:47, John Adair <g...@enterpoint.co.uk> wrote:
> We have a range of solutions but a lot depends on what sort of drive
> you want and how that is going to be implemented. For low cost board
> look athttp://www.enterpoint.co.uk/polmaddie/polmaddie3.html. 60 3V3
> I/O there and the 3 headers are on 0.1"/2.54mm grid so you can make
> stripboard lash-ups to add on.
>
> John Adair
> Enterpoint Ltd.
>
> On Feb 3, 4:07=A0pm, LM <sala.n...@mail.com> wrote:
>
> > I would like to see what kind PWM LED control I could do with FPGA and
> > of course just play with the kit to see what else I can do with it. A
> > FPGA (kit)with plenty of pins and low price is good.
>
> > I am not willing to re invent all the the wheels there is and
> > programming some PC interface, so the kit or FPGA should have some
> > communication port built in. There are plenty of LED controllers
> > already, so that wheel I am happy to reinvent.

I guess I did not put a question here. But you guessed correctly, a
starter kit pointer or name is what I want. It seems I'll know a good
starter kit, when I dont need them any more. 29.9$ is surely a good
price. I am willing to pay a little more though. That board 3 from
Enterpoint is surely one alternative.

Some more info of what I have in mind. A decent ("centipede") cpu has
about 40 free IO pins. That means it could PWM drive that much LEDs. I
am thinking a very simple way, just controlling one LED with one pin.
Programming may become difficult because of timing and so on. I think
I could better describe a PWM control with logic, and timing seems to
be easier.

I need also a bus to get data from PC. What the bus is, is not
important now. Of course, if I have to program it my self, it should
be simple.

Many pins, heh, more than 18. Basic logic outputs, Cmos levels and
speed. I am not going to drive LEDS with FPGA outputs directly. What
is there in the kit is a different matter, but buffers are easy to
build.

With thanks
Leif M

Article: 153351
Subject: Free GUI top level integration tool for Verilog and VHDL
From: vtxsupport@hotmail.com
Date: Sun, 5 Feb 2012 07:59:27 -0800 (PST)
Links: << >>  << T >>  << A >>
VTC has been developed for very long time. It has been used in many
projects and proven to be useful. It should have been available for
you long time ago. But I have to spend many years to study laws alone
to face to the lawyers from leading EDA, because the counsel fee is
too expensive for me. Not long ago, finally my patent was judged to be
valid. So I have time to build this website to show some of my ideas.
http://www.veriloghdl.org
Thanks.

Article: 153352
Subject: 'x' state on one bit of the input bus of an adder cause the output
From: Haiwen <heavenfish@gmail.com>
Date: Sun, 5 Feb 2012 21:39:03 -0800 (PST)
Links: << >>  << T >>  << A >>
I have an adder:
module adder(
input [1:0] add1,
input [1:0] add2,
output [2:0] addout
);
assign addout = add1 + add2;
endmodule

The input is:
add1 = 2'bx0;
add2 = 2'b00;

The RTL simulation result is:
addout = 3'bxxx;

The Timing simulation result is:
addout = 3'b0x0;
and this is what I expected.

How can I solve the mismatch in RTL simulation?

Article: 153353
Subject: Re: Xilinx Artix-7 availability
From: Neill Arnell <neilla@pipstechnology.co.uk>
Date: Mon, 06 Feb 2012 08:52:01 +0000
Links: << >>  << T >>  << A >>
On 04/02/2012 12:14, Arne Pagel wrote:
> did anybody hear something about the availability about the Xilinx
> Artix-7 series?
>
> Especially I am interested in the XC7A8 or XC7A15 in the FTG256 Package.
>

Are those devices still going to be offered?

The latest datasheet has the smallest Artix device as the XC7A100T, 
which is larger than the smallest Kintex device.


Article: 153354
Subject: Problem with post-route simulation
From: aleksa <aleksazr@gmail.com>
Date: Mon, 6 Feb 2012 03:38:56 -0800 (PST)
Links: << >>  << T >>  << A >>
The whole ISE project (VHDL) can be found here:
http://www.mediafire.com/?wvvvcjrjl67lcnr

Besides ISE project, it also contains two print-screen GIFs,
behavioral.gif and post-route.gif.

behavioral.gif shows
@40ns : start = 1, data = AAAA
at next rising CLK edge CS goes LOW
then, SDI serially transmits data (101010...)
finally, CS goes HIGH (215ns)

That is exactly what I would expect from the VHDL code.

But the post-route.gif shows something completely
different, and I don't know why.

What am I doing wrong?


Article: 153355
Subject: Re: Xilinx Artix-7 availability
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Mon, 06 Feb 2012 07:42:08 -0600
Links: << >>  << T >>  << A >>
>did anybody hear something about the availability about the Xilinx Artix-7
series?
>
>Especially I am interested in the XC7A8 or XC7A15 in the FTG256 Package.
>
>
>regards
>    Arne

Sign a Non-Disclosure Agreement with Xilinx, and I'm fairly sure that you
will be told...
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153356
Subject: Re: 'x' state on one bit of the input bus of an adder cause the
From: Chris Maryan <kmaryan@gmail.com>
Date: Mon, 6 Feb 2012 06:42:53 -0800 (PST)
Links: << >>  << T >>  << A >>
The "timing" simulation is probably on a post synthesis or post fit netlist=
, where the "+" has been converted to a proper adder in whatever logic is a=
ppropriate for your application. Describe a complete adder out of plain gat=
es and you will get what you want. (i.e. describe a ripple-carry adder or s=
ome other architecture)

Moreover, why do you care about the details of the output of an adder with =
an X input?

Chris

Article: 153357
Subject: Re: Problem with post-route simulation
From: aleksa <aleksazr@gmail.com>
Date: Mon, 6 Feb 2012 07:48:53 -0800 (PST)
Links: << >>  << T >>  << A >>
http://img826.imageshack.us/img826/3067/designp.gif
This GIF shows how I actually start the simulator.

If I select "tb - behavior (tb.vhd)" in the upper section
(and double click Simulate Behavioral Model below)
I get the results of  behavioral.gif

If I select "uut - DAC_STATE...so on" i get all signals as U, but, as
a bonus,
I do get internal signals in the list, which I don't get otherwise.

Really annoying..

Article: 153358
Subject: Re: Problem with post-route simulation
From: aleksa <aleksazr@gmail.com>
Date: Mon, 6 Feb 2012 12:30:23 -0800 (PST)
Links: << >>  << T >>  << A >>
As Gabor suggested (in the Xilinx forums), post-route requires 100ns
delay for the GSR.
After changing the first line to "wait for 140 ns;" it now works.
Thanks Gabor, once again.

As for the internal signals, that is for another thread.

Article: 153359
Subject: Re: Problem with post-route simulation
From: aleksa <aleksazr@gmail.com>
Date: Mon, 6 Feb 2012 13:24:53 -0800 (PST)
Links: << >>  << T >>  << A >>
Ok, if someone else has problems with internal signals, this is how I
do it now:

in this GIF http://img826.imageshack.us/img826/3067/designp.gif
use "tb - behavior (tb.vhd)", NOT "uut - DAC_STATE...so on.."

to view internal signals, open Instances and processes panel (and
Objects, of course)
open "tb", and click on "uut" to see internal signals,
as shown here http://img834.imageshack.us/img834/4431/inernalbehavioral.gif
drag signals and click on Re-launch.

I'm not saying this is the way to go, but I'm using it now.

Article: 153360
Subject: Re: Difference between Xilinx isim and modelsim
From: Andy <jonesandy@comcast.net>
Date: Tue, 7 Feb 2012 07:50:02 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 2, 6:48=A0pm, Alan Fitch <a...@invalid.invalid> wrote:
> On 03/02/12 00:16, Alan Fitch wrote:
>
>
>
>
>
> > On 02/02/12 16:47, Andy wrote:
> >> On Feb 1, 5:08 pm, Alan Fitch <a...@invalid.invalid> wrote:
> > <snip>
>
> >>> I believe it is a bug in Isim.
>
> >>> I'm basing this on reading section 8.1 of the VHDL 2002 standard "wai=
t
> >>> statement" where it says there is an implicit sensitivity list derive=
d from
>
> >>> - A function call, apply this rule to every actual designator in ever=
y
> >>> parameter association
>
> >>> and
>
> >>> =97 An indexed name whose prefix denotes a signal, add the longest st=
atic
> >>> prefix of the name to the
> >>> sensitivity set and apply this rule to all expressions in the indexed=
 name
>
> >>> As you're using vec(1), the longest static prefix is behavioural.vec(=
1),
> >>> so vec(1) should trigger the wait until whenever it changes.
>
> >> I believe that is not correct. The LSP is ...vec (the whole vector).
> >> So processes that appear to be sensitive to one bit of a vector are
> >> also sensitive to other bits in the vector, but the
> >> rising_edge(vec(1)) function invoked by the wait statement is only
> >> looking at vec(1).
>
> > Hi Andy,
> > =A0I was (perhaps foolishly) assuming that because 1 is a constant, the
> > slice could be statically determined - but you could well be correct, I
> > really need to go away and read the definition of longest static prefix
> > again
>
> Ok, here's the text from 1076-2002
>
> "Furthermore, a name is said to be a locally static name if and only if
> one of the following conditions hold:
>
> ...
>
> =97 The name is an indexed name whose prefix is a locally static name, an=
d
> every expression that appears as part of the name is a locally static
> expression.
>
> =97 The name is a slice name whose prefix is a locally static name and
> whose discrete range is a locally static discrete range.
>
> A static signal name is a static name that denotes a signal. The longest
> static prefix of a signal name is the name itself, if the name is a
> static signal name; otherwise, it is the longest prefix of the name that
> is a static signal name. Similarly, a static variable name is a static
> name that denotes a variable, and the longest static prefix of a
> variable name is the name itself, if the name is a static variable name;
> otherwise, it is the longest prefix of the name that is a static
> variable name.
>
> Examples:
> S(C,2) --A static name: C is a static constant.
> R(J to 16) --A nonstatic name: J is a signal.
> --R is the longest static prefix of R(J to 16).
> T(n) --A static name; n is a generic constant.
> T(2) --A locally static name."
> "
>
> So I think I was right,
>
> regards
> Alan
>
> --
> Alan Fitch- Hide quoted text -
>
> - Show quoted text -

I will have to go back and read the definition of LSP. I agree with
your assessment that these are locally static names; the question is
"what is the relation between a locally static name for an element or
slice of an aggregate, and the longest static prefix for  than element
or slice?" It was my understanding that if there is a named aggregate
that contains the object referred to by the locally static name, then
the aggregate is still the LSP, not the locally static name. It likely
has to do with whether events are tracked separately on inidividual
elements of a named aggregate signal, or whether they are only tracked
at the aggregate level.

And I may be entirely wrong...

Thanks for the discussion,

Andy

Article: 153361
Subject: Re: 'x' state on one bit of the input bus of an adder cause the
From: Andy <jonesandy@comcast.net>
Date: Tue, 7 Feb 2012 08:03:10 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 6, 8:42=A0am, Chris Maryan <kmar...@gmail.com> wrote:
>
> Moreover, why do you care about the details of the output of an adder wit=
h an X input?
>
> Chris

Because the actual behavior of the HW is implementation dependent, the
RTL operator does not attempt to define its behavior for inputs
containing meta-values, beyond the whole result being 'unknown'.

To compare the results, I would take the RTL outputs, run them through
a 'X' to '-' ('unknown' to 'dont care') conversion (probably need to
write your own function), and then use std_match() to compare the RTL
vs gate level outputs.

This in effect says that for verification, if the output of the RTL is
not known, then the output of the gate level sim is of no consequence.

Andy

Article: 153362
Subject: Re: Design Notation VHDL or Verilog?
From: Andy <jonesandy@comcast.net>
Date: Tue, 7 Feb 2012 08:22:19 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 5:43=A0am, n...@puntnl.niks (Nico Coesel) wrote:
> Record bundles can be bi-directional in VHDL!

That's the problem; every element of a VHDL bidirectional record port
is bidirectional. You have to use resolved types for each element, and
remember to assign benign driven values to elements you want to be
input only. It can be done, but it gets ugly.

Sometimes (especially testbenches) it is worth the work, but it would
be worth even more to be able to define custom record modes for record
port types (e.g. master, slave, observer, etc modes for a record port
representing a bus interface, each defining different individual in/
out/inout/etc modes on individual record elements).

Andy

Article: 153363
Subject: Re: Design Notation VHDL or Verilog?
From: Andy <jonesandy@comcast.net>
Date: Tue, 7 Feb 2012 08:45:14 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 4:37=A0am, Petter Gustad <newsmailco...@gustad.com> wrote:
> Andy <jonesa...@comcast.net> writes:
> > For verification, SV is indeed really nice. However, a new open source
> > VHDL Verification Methodology (VVM) library of VHDL packages has
> > emerged that provides VHDL with some of the capabilities of SV with
> > OVM/UVM.
>
> I took a link at some of the links posted here previously, it looks
> nice and it's an improvement. But as far as I could tell it lacked
> polymorphism and inheritance.

Actually, being built around VHDL protected types, it has some amount
of both. Not nearly as clean or capable as SV though.

Andy

Article: 153364
Subject: Re: 'x' state on one bit of the input bus of an adder cause the output bus be all 'x' during simulation
From: "Snowy" <snowybrown@charter.net>
Date: Tue, 7 Feb 2012 10:53:16 -0600
Links: << >>  << T >>  << A >>
It takes some bit manipulation to handle unknowns exactly.  That takes 
programmer time and CPU time (I've done it).  Most likely they traded off 
exactness for speed.  Usually, you don’t care about the result unless it is 
totally defined.  As someone else suggested, you might need to write your 
own model if you want exactness.

Gary

"Haiwen"  wrote in message 
news:3d0b033f-3994-43d5-a1e6-0fb463b0a86f@n8g2000pbc.googlegroups.com...

I have an adder:
module adder(
input [1:0] add1,
input [1:0] add2,
output [2:0] addout
);
assign addout = add1 + add2;
endmodule

The input is:
add1 = 2'bx0;
add2 = 2'b00;

The RTL simulation result is:
addout = 3'bxxx;

The Timing simulation result is:
addout = 3'b0x0;
and this is what I expected.

How can I solve the mismatch in RTL simulation? 


Article: 153365
Subject: Life after XDL
From: Neil Steiner <neil.steiner@east.isi.edu>
Date: Tue, 07 Feb 2012 12:57:47 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------010406050703000003000604
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

If you know and love XDL or XDLRC, and if you believe that the research
community's access to these tools provides a benefit to Xilinx, this is
your opportunity to speak up.  The xdl tool will no longer be available
as of ISE 14, and unofficial word is that Xilinx does not intend to
provide equivalent capability.  We don't believe they're deliberately
trying to withhold that capability:  We simply think they see it as a
distraction that provides no benefit for them.

/For those who may be unfamiliar with these tools, XDL is a format that
can be converted to or from mapped NCD, allowing the user to modify any
part of their circuit or its placement or routing, or to perform
arbitrary placement and routing of their own.  XDLRC provides all of the
logic and interconnect data for real Xilinx devices, and enables
research into CAD algorithms for real devices.
/
A colleague from BYU (representing RapidSmith) and I (representing Torc)
are scheduled to meet with the Xilinx software folks in two weeks to
discuss this matter, and to appeal for continued functionality
equivalent to XDL and XDLRC.  We have no wish to barrage or pressure
them in any way.  The data is theirs to do with as they think best.  But
to the extent that our community's access to XDL benefits them, we would
like to present that case to them.

I am collecting and framing our arguments, and am open to any
contributions from the comp.arch.fpga community.  Any of the following
would be helpful to our cause, in rough decreasing order of importance. 
And I relax the strict meaning of XDL here to include capabilities and
low-level device knowledge enabled by XDL:

  * Evidence that XDL is used by Xilinx paying customers.
  * Evidence that XDL is used by real companies or in real products (or
    anything in orbit or beyond).
  * Evidence that XDL enables truly novel research and helps
    differentiate Xilinx from competitors.
  * Evidence that XDL has encouraged universities to adopt Xilinx tools
    in classes.
  * Evidence that work from the research community based on access to
    Xilinx data has benefited research or development at Xilinx.
  * Evidence that XDL has helped researchers win funding.
  * Evidence that access to Xilinx data has resulted in a good pool of
    candidates for Xilinx to hire from.

We do not believe the community's mere desire for access to XDL and
XDLRC carries any weight with Xilinx.  But Xilinx is a commercial
company, and anything that aligns with their business model or
objectives, or increases their sales and market share, is likely to
catch their attention.

XDL and related capabilities have been central to my research for the
past ten years, so I am well aware of what we stand to lose.  There are
some sympathetic voices within Xilinx, but we probably should not ask
them to make the case for us:  We need to do so ourselves.  If you have
good suggestions, feel free to respond here, but please also copy me at
mailto:neil.steiner@isi.edu?subject=comp.arch.fpga%20XDL%20suggestions.

Regards,


--------------010406050703000003000604
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    If you know and love XDL or XDLRC, and if you believe that the
    research community's access to these tools provides a benefit to
    Xilinx, this is your opportunity to speak up.&nbsp; The xdl tool will no
    longer be available as of ISE 14, and unofficial word is that Xilinx
    does not intend to provide equivalent capability.&nbsp; We don't believe
    they're deliberately trying to withhold that capability:&nbsp; We simply
    think they see it as a distraction that provides no benefit for
    them.<br>
    <br>
    <i>For those who may be unfamiliar with these tools, XDL is a format
      that can be converted to or from mapped NCD, allowing the user to
      modify any part of their circuit or its placement or routing, or
      to perform arbitrary placement and routing of their own.&nbsp; XDLRC
      provides all of the logic and interconnect data for real Xilinx
      devices, and enables research into CAD algorithms for real
      devices.<br>
    </i><br>
    A colleague from BYU (representing RapidSmith) and I (representing
    Torc) are scheduled to meet with the Xilinx software folks in two
    weeks to discuss this matter, and to appeal for continued
    functionality equivalent to XDL and XDLRC.&nbsp; We have no wish to
    barrage or pressure them in any way.&nbsp; The data is theirs to do with
    as they think best.&nbsp; But to the extent that our community's access
    to XDL benefits them, we would like to present that case to them.<br>
    <br>
    I am collecting and framing our arguments, and am open to any
    contributions from the comp.arch.fpga community.&nbsp; Any of the
    following would be helpful to our cause, in rough decreasing order
    of importance.&nbsp; And I relax the strict meaning of XDL here to
    include capabilities and low-level device knowledge enabled by XDL:<br>
    <ul>
      <li>Evidence that XDL is used by Xilinx paying customers.</li>
      <li>Evidence that XDL is used by real companies or in real
        products (or anything in orbit or beyond).</li>
      <li>Evidence that XDL enables truly novel research and helps
        differentiate Xilinx from competitors.</li>
      <li>Evidence that XDL has encouraged universities to adopt Xilinx
        tools in classes.<br>
      </li>
      <li>Evidence that work from the research community based on access
        to Xilinx data has benefited research or development at Xilinx.<br>
      </li>
      <li>Evidence that XDL has helped researchers win funding.</li>
      <li>Evidence that access to Xilinx data has resulted in a good
        pool of candidates for Xilinx to hire from.<br>
      </li>
    </ul>
    <p>We do not believe the community's mere desire for access to XDL
      and XDLRC carries any weight with Xilinx.&nbsp; But Xilinx is a
      commercial company, and anything that aligns with their business
      model or objectives, or increases their sales and market share, is
      likely to catch their attention.<br>
    </p>
    <p>XDL and related capabilities have been central to my research for
      the past ten years, so I am well aware of what we stand to lose.&nbsp;
      There are some sympathetic voices within Xilinx, but we probably
      should not ask them to make the case for us:&nbsp; We need to do so
      ourselves.&nbsp; If you have good suggestions, feel free to respond
      here, but please also copy me at <a
href="mailto:neil.steiner@isi.edu?subject=comp.arch.fpga%20XDL%20suggestions">mailto:neil.steiner@isi.edu?subject=comp.arch.fpga%20XDL%20suggestions</a>.<br>
    </p>
    <p>Regards,<br>
    </p>
  </body>
</html>

--------------010406050703000003000604--

Article: 153366
Subject: Re: Design Notation VHDL or Verilog?
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 07 Feb 2012 21:14:07 GMT
Links: << >>  << T >>  << A >>
Andy <jonesandy@comcast.net> wrote:

>On Feb 3, 5:43=A0am, n...@puntnl.niks (Nico Coesel) wrote:
>> Record bundles can be bi-directional in VHDL!
>
>That's the problem; every element of a VHDL bidirectional record port
>is bidirectional. You have to use resolved types for each element, and
>remember to assign benign driven values to elements you want to be
>input only. It can be done, but it gets ugly.

I never had that problem when synthesizing for Xilinx devices.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 153367
Subject: Re: Design Notation VHDL or Verilog?
From: Andy <jonesandy@comcast.net>
Date: Thu, 9 Feb 2012 11:42:17 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 7, 3:14=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
> I never had that problem when synthesizing for Xilinx devices.

Did you simulate your RTL using bidirectional ports? That's where the
default driver problem arises, on inout ports that are only read (from
the inside).

Synthesis can take a lot of liberty with your RTL description because
of the static nature of the analysis of the code, and the fact that
unknowns are don't cares in synthesis, which means the synthesis tool
can do as it pleases, which is usually what pleases the most customers
most of the time.

Andy


Article: 153368
Subject: Re: Design Notation VHDL or Verilog?
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 09 Feb 2012 21:32:46 GMT
Links: << >>  << T >>  << A >>
Andy <jonesandy@comcast.net> wrote:

>On Feb 7, 3:14=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
>> I never had that problem when synthesizing for Xilinx devices.
>
>Did you simulate your RTL using bidirectional ports? That's where the
>default driver problem arises, on inout ports that are only read (from
>the inside).

I didn't simulate that particular code. It was back in the days that
simulation software wasn't available if you wanted to keep your arms
and legs.

>Synthesis can take a lot of liberty with your RTL description because
>of the static nature of the analysis of the code, and the fact that
>unknowns are don't cares in synthesis, which means the synthesis tool
>can do as it pleases, which is usually what pleases the most customers
>most of the time.

AFAIK: for RTL to synthesize each signal needs one driver. Even if it
would drive the signal tristate. It probably depends on the tools. My
experience is limited to Xilinx.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 153369
Subject: Dangling all pins, DIA0 through DIA31
From: aleksa <aleksazr@gmail.com>
Date: Fri, 10 Feb 2012 02:41:25 -0800 (PST)
Links: << >>  << T >>  << A >>
I'm creating a dual-port ROM, both sides are the same: 7-bit address,
32-bit data.
Very simple ISE 13.3 project can be downloaded from here:
http://www.mediafire.com/?xmf55vwdb14qvbf
=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF
Both Implementing and Generating the bit file gives warning like this
one:
PhysDesignRules:812 - Dangling pin <DIA0>
all the way from DIA0 to DIA31.

I'm aware of this page: http://www.xilinx.com/support/answers/31378.htm
but am not sure if that applies here.

Am I doing something wrong here?

Testing on XC3S50A.

Article: 153370
Subject: Re: Dangling all pins, DIA0 through DIA31
From: aleksa <aleksazr@gmail.com>
Date: Fri, 10 Feb 2012 03:22:20 -0800 (PST)
Links: << >>  << T >>  << A >>
AFAIC, this is a bug and should be fixed.
I'm creating a ROM, not a RAM.

Article: 153371
Subject: Re: Dangling all pins, DIA0 through DIA31
From: sbattazzo <sbattazzo@gmail.com>
Date: Fri, 10 Feb 2012 13:33:44 +0100
Links: << >>  << T >>  << A >>
On 2012-02-10 11:41, aleksa wrote:
> I'm creating a dual-port ROM, both sides are the same: 7-bit address,
> 32-bit data.
> Very simple ISE 13.3 project can be downloaded from here:
> http://www.mediafire.com/?xmf55vwdb14qvbf
> 
> Both Implementing and Generating the bit file gives warning like this
> one:
> PhysDesignRules:812 - Dangling pin<DIA0>
> all the way from DIA0 to DIA31.
>
> I'm aware of this page: http://www.xilinx.com/support/answers/31378.htm
> but am not sure if that applies here.
>
> Am I doing something wrong here?
>
> Testing on XC3S50A.

I think this is probably OK. Have you simulated your design and/or seen 
that it works as you expect in hardware?

I have often seen similar warnings for unused address lines on block 
RAMs for Microblaze or PPC designs. The ROM and RAM are made from the 
same Block RAM primitives, so the same connection lines are there, even 
if not implemented.

Maybe somebody else will chime in with a more concrete answer though.

Steve

Article: 153372
Subject: Re: Design Notation VHDL or Verilog?
From: Andy <jonesandy@comcast.net>
Date: Fri, 10 Feb 2012 06:29:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 9, 3:32=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
> Andy <jonesa...@comcast.net> wrote:
> >On Feb 7, 3:14=3DA0pm, n...@puntnl.niks (Nico Coesel) wrote:
> >> I never had that problem when synthesizing for Xilinx devices.
>
> >Did you simulate your RTL using bidirectional ports? That's where the
> >default driver problem arises, on inout ports that are only read (from
> >the inside).
>
> I didn't simulate that particular code. It was back in the days that
> simulation software wasn't available if you wanted to keep your arms
> and legs.
>
> >Synthesis can take a lot of liberty with your RTL description because
> >of the static nature of the analysis of the code, and the fact that
> >unknowns are don't cares in synthesis, which means the synthesis tool
> >can do as it pleases, which is usually what pleases the most customers
> >most of the time.
>
> AFAIK: for RTL to synthesize each signal needs one driver. Even if it
> would drive the signal tristate. It probably depends on the tools. My
> experience is limited to Xilinx.
>
> --
> Failure does not prove something is impossible, failure simply
> indicates you are not using the right tools...
> nico@nctdevpuntnl (punt=3D.)
> --------------------------------------------------------------

Most synthesis tools will convert multiple tri-state drivers on a
signal into multiplexers, since most FPGAs do not support internal tri-
state busses any more. They assume that the various tri-state enables
are mutually exlusive (how else would the tri-state bus have worked?),
so a prioritlyless multiplexer is constructed. This can be a handy way
of specifying a distributed priorityless mux.

Most synthesis tools will convert default 'U' drivers to
"undriven" (nothing), which is different behavior from the SL
resolution function in simulation (they issue a warning about that).

Andy


Article: 153373
Subject: Re: Dangling all pins, DIA0 through DIA31
From: aleksa <aleksazr@gmail.com>
Date: Fri, 10 Feb 2012 07:23:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 10, 1:33=C2=A0pm, sbattazzo <sbatta...@gmail.com> wrote:
> On 2012-02-10 11:41, aleksa wrote:
>
>
>
>
>
> > I'm creating a dual-port ROM, both sides are the same: 7-bit address,
> > 32-bit data.
> > Very simple ISE 13.3 project can be downloaded from here:
> >http://www.mediafire.com/?xmf55vwdb14qvbf
> > =EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=
=BF
> > Both Implementing and Generating the bit file gives warning like this
> > one:
> > PhysDesignRules:812 - Dangling pin<DIA0>
> > all the way from DIA0 to DIA31.
>
> > I'm aware of this page:http://www.xilinx.com/support/answers/31378.htm
> > but am not sure if that applies here.
>
> > Am I doing something wrong here?
>
> > Testing on XC3S50A.
>
> I think this is probably OK. Have you simulated your design and/or seen
> that it works as you expect in hardware?

No, I haven't simulated it, it is too simple. (did you get the file?)
And I haven't tested it with real hardware, bc that was just a test.

Maybe someone has 13.4 and has time to test it there? (synthesize and
implement)

> I have often seen similar warnings for unused address lines on block
> RAMs for Microblaze or PPC designs. The ROM and RAM are made from the
> same Block RAM primitives, so the same connection lines are there, even
> if not implemented.
>
> Maybe somebody else will chime in with a more concrete answer though.
>
> Steve


Article: 153374
Subject: Re: Dangling all pins, DIA0 through DIA31
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 10 Feb 2012 19:00:07 GMT
Links: << >>  << T >>  << A >>
aleksa <aleksazr@gmail.com> wrote:

>I'm creating a dual-port ROM, both sides are the same: 7-bit address,
>32-bit data.
>Very simple ISE 13.3 project can be downloaded from here:
>http://www.mediafire.com/?xmf55vwdb14qvbf
>=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF
>Both Implementing and Generating the bit file gives warning like this
>one:
>PhysDesignRules:812 - Dangling pin <DIA0>
>all the way from DIA0 to DIA31.
>
>I'm aware of this page: http://www.xilinx.com/support/answers/31378.htm
>but am not sure if that applies here.
>
>Am I doing something wrong here?

No. Open pins should generate a warning. Just tie them to '0'.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------



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