Clock Edge notation

[Denkedran Joe]

<MikeShepherd564@btinternet.com> wrote:

How about sending the excess data by post?

Joker!

What makes this an electronics problem anyway?

The hardware implementation on an FPGA plattform makes it an electronics
problem. So, think again! Next time you better come up with a more
sophisticated answer...

 

How about sending the excess data by post?
Joker!

What makes this an electronics problem anyway?
The hardware implementation on an FPGA plattform makes it an electronics
problem. So, think again! Next time you better come up with a more
sophisticated answer...

Let me put it more clearly. You fail to distinguish the separate
problems of algorithm and implementation. There is nothing
specifically electronic about this problem, so it doesn't concern
FPGAs in general nor VHDL in particular.

If you don't like what's on TV, does that make it an electronic
problem?

 

[Mark McDougall]

Dave Pollum wrote:

but you can't assign
values to input port "inp_i".

And he hasn't... ?!?

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

 

[Mark McDougall]

jidan1@hotmail.com wrote:

I am using Spartan-3 XC31000. You can enable on/off pull-up/pull-down
resistors with ISE; however, i would like to do this in VHDL so that i
can enable them during runtime.

Are you talking about having "pull-ups" _inside_ the FPGA, which can be
turned on/off whilst the image is running?

I've done a few designs with an "open-collector" bus connecting several
internal modules, plus an external IO... each internal module uses the
"resolved" bus signal as input, and drives "oe" as an output. The
top-level "resolved" signal is computed combinatorially from the external
input plus the internal oe signals... and of course the oe's combine to
drive the I/O pin direction as well.

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

 

Are you talking about having "pull-ups" _inside_ the FPGA, which can be
turned on/off whilst the image is running?

Exactly. But it seems that it's unfortunatly not possible while the
FPGA is running; it has to be done during configuration ;(

JJ

 

[Kim Enkovaara]

Jan wrote:

You cannot dynamically enable/disable pullups in xilinx devices.
You can instantiate a PULLUP/PULLDOWN primitive, but it cannot change
after configuration..
see http://toolbox.xilinx.com/docsan/xilinx9/books/docs/s3edl/s3edl.pdf

For Virtex series it might be possible to do this with dynamic
reconfiguration. But for Spartan the pullup/down is not
dynamic setting.

--Kim

 

[Dave Pollum]

On Dec 4, 10:25 pm, Mark McDougall <ma...@vl.com.au> wrote:

Dave Pollum wrote:
but you can't assign
values to input port "inp_i".

And he hasn't... ?!?

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

DOH! I missed "s_inp_i". Next time I'll be sure to wear my glasses!
-Dave Pollum

 

[HT-Lab]

"Ole Nielsby" <ole.nielsby@tekare-you-spamminglogisk.dk> wrote in message
news:477ebc4d$0$2093$edfadb0f@dtext02.news.tele.dk...

This is to inform you of a project that might interest VHDL
developers, or functional programming or wxWidgets
developers.

I am experimenting with the use of my PILS language for
producing free tools for parsing and manipulating VHDL,
using a (wxWidgets based) GUI that lets you select
and view individual operations.

This is still in a very early stage, but VHDL'ers might have
ideas for what the Codecomb tools should do to their VHDL.
So far I implemented two rather trivial transformers: one that
converts keywords to upper case and one that inserts the
optional tokens in END...; sequences - but tell me your
wishes and I might give it a try.

Well....., what would be nice if you could accept VHDL2006 and translate it
back to VHDL2002. I understand that this might not work for all new language
constructs but it might be doable for features like process(all), simplified
case, case with dontcare values, expressions in portmaps etc etc.

Hans
www.ht-lab.com

PS It would be easier if you use plain zip/tar/gz compression for your work
instead of 7-zips.

(If your heart is in your dreams...)

The demo works by generating replacement instructions
from the syntax trees. The GUI then displays the replacers
and the VHDL, allowing you to switch them on/off with
Ins/Del keys, which is a fast means for selecting the
replacements you want.

The parser is a funny beast - I banged my head flat against
BFN and LALR, and dumped in favour of coding a state
transformation machine directly in PILS, with a diagnostic
GUI that allows you to see the parser working step by step,
and can point you to the PILS rule responsible to a particular
step.

If you want to see the demo: http://pils.org
You have to unpack it and follow the instructions in the
readme. (No installer. No registry mess.)

The exact terms for the Codecomb VHDL tool aren't clear but
it will be open source and you won't be charged for using it.

PILS is freeware but I won't support military or weaponry
applications and therefore can't set up a sourceforge project,
as the OSI terms forbid discrimination of application fields.
I haven't gotten around to setting up a proper site for it yet,
producing tools of value is of higher priority than web design
right now.

The PILS language is documented by an openoffice document
which is included in the demo archive (but requires openoffice).

Note: FUT has been set to comp.lang.vhdl. If you want to discuss
functional programming or wxWidgets interfacing, please set the ng.

Ole Nielsby, Danish Technological Institute http://www.dti.dk

Btw thanks to those who answered my questions on vhdl grammar
technicalities in comp.lang.vhdl. I might ask more...

 

[Dwayne Dilbeck]

I would however advise you to have a quick google on some of the
verification techniques (if you don't already know them) such as
functional coverage, assertions based verification, constraint random and
transaction level modelling, nothing fancy just understand their
advantages and disadvantages and some of the languages they use. Having
said that I suspect a lot of verfication is still done using nothing more
than a VHDL/Verilog testbench in a similar trend to some FPGA engineers
just loading the design on the board and see if it works

Thank you Hans for the feedback. I am starting to have a very confident
feeling. Especially when the areas you mentioned to google turned out to be
areas I am very familiar with. I have been testing those areas in our EDA
tools, I have a very firm grasp on those concepts and where they fall apart
atleast for one set of EDA tools.

Thank you everyone for the feedback the resume's are going out today.

 

[Uncle Noah]

On Jan 17, 5:59 am, Amal <akhailt...@gmail.com> wrote:

Does anyone have a copy of Forte Design (CynApps) opensource Cynlib?

I appreciate if you can send me a copy.
-- Amal

Hi

i have this one: cynlib.1.2.1.source.tar.gz (3,876,003bytes)

I'll check the licensing issues (if i can pass it to you or not). But,
first of all, is this version OK for you?

And what about the company, it might be best if you asked them about
the legality of this.

Kind regards
Nikolaos Kavvadias

 

[Amal]

On Jan 17, 11:43 am, Uncle Noah <nk...@skiathos.physics.auth.gr>
wrote:

On Jan 17, 5:59 am, Amal <akhailt...@gmail.com> wrote:

Does anyone have a copy of Forte Design (CynApps) opensource Cynlib?

I appreciate if you can send me a copy.
-- Amal

Hi

i have this one: cynlib.1.2.1.source.tar.gz (3,876,003bytes)

I'll check the licensing issues (if i can pass it to you or not). But,
first of all, is this version OK for you?

And what about the company, it might be best if you asked them about
the legality of this.

Kind regards
Nikolaos Kavvadias

I searched the net. They released this and another tool to open
source community a long time ago. There is no mention of this
anywhere on their web site anymore.

Whatever version is fine. Not looking for any specific version
really.

-- Amal

 

[Moikel]

Hi,

I'm writing a state machine for a control path for a hardware neural
network implementation. I'm using Xilinx ISE 8.2i.

I have a variable "result". This variable is manipulated bit-wise
(i.e. single bits at specified indices are set and cleared as the
state machine is running). Here are the lines involving the variable:

variable result : SIGNED(31 downto 0);

uCURRENT_OUT <= STD_LOGIC_VECTOR(result);
result := (others=> '0');
result(TO_INTEGER(i)) := '1';
result(TO_INTEGER(i)) := '0';

if(STD_LOGIC_VECTOR(result) = uPrev_IN) then
NS <= S11;

When I sythesise this in Xilinx, the synthesis is successful, but
gives warnings. The warning is:

"WARNING:Xst:737 - Found 1-bit latch for signal <result_1>.
INFO:Xst:2371 - HDL ADVISOR - Logic functions respectively driving the
data and gate enable inputs of this latch share common terms. This
situation will potentially lead to setup/hold violations and, as a
result, to simulation problems. This situation may come from an
incomplete case statement (all selector values are not covered). You
should carefully review if it was in your intentions to describe such
a latch."

It gives a large number of these warnings, all very similar, but with
<result_4>, <result_27>, <result_28> etc. I have checked and I dont
have any incomplete case statements.

I am anxious to solve this issue. Can anyone help me with this?

Thanks,

Mike

 

[Mike Treseler]

Moikel wrote:

When I sythesise this in Xilinx, the synthesis is successful, but
gives warnings. The warning is:

"WARNING:Xst:737 - Found 1-bit latch for signal <result_1>.

Synthesis completes without error, but it made
an unexpected latch, so your design intent
has not been properly described.

Consider basing your design on a synchronous template.
That rules out latches.
Debug your design using the rtl viewer
and a simulator. Good luck.

-- Mike Treseler

 

[jtw]

Assuming the order you wrote the applicable lines is the order they appear
in the code, then the first value of result is based on the previous pass,
when result was assigned values. Hence, a latch.

You haven't provided the sensitivity list, or conditions, so this is just a
guess; but then, since the tool inferred a latch, this must not be in a
typical clocked process.

JTW

"Moikel" <obviouslyadummy@gmail.com> wrote in message
news:664fe0ea-d671-4792-ab3f-69a1041f5094@m34g2000hsc.googlegroups.com...

Hi,

I'm writing a state machine for a control path for a hardware neural
network implementation. I'm using Xilinx ISE 8.2i.

I have a variable "result". This variable is manipulated bit-wise
(i.e. single bits at specified indices are set and cleared as the
state machine is running). Here are the lines involving the variable:

variable result : SIGNED(31 downto 0);

uCURRENT_OUT <= STD_LOGIC_VECTOR(result);
result := (others=> '0');
result(TO_INTEGER(i)) := '1';
result(TO_INTEGER(i)) := '0';

if(STD_LOGIC_VECTOR(result) = uPrev_IN) then
NS <= S11;

When I sythesise this in Xilinx, the synthesis is successful, but
gives warnings. The warning is:

"WARNING:Xst:737 - Found 1-bit latch for signal <result_1>.
INFO:Xst:2371 - HDL ADVISOR - Logic functions respectively driving the
data and gate enable inputs of this latch share common terms. This
situation will potentially lead to setup/hold violations and, as a
result, to simulation problems. This situation may come from an
incomplete case statement (all selector values are not covered). You
should carefully review if it was in your intentions to describe such
a latch."

It gives a large number of these warnings, all very similar, but with
result_4>, <result_27>, <result_28> etc. I have checked and I dont
have any incomplete case statements.

I am anxious to solve this issue. Can anyone help me with this?

Thanks,

Mike

 

[Moikel]

Hello,

Xilinx is giving me the following warning during synthesis:

=========================================================================
* Low Level
Synthesis *
=========================================================================
WARNING:Xst:1988 - Unit <control>: instances <Mcompar__cmp_lt0001>,
<Mcompar__cmp_ge0001> of unit <LPM_COMPARE_1> and unit <LPM_COMPARE_4>
are dual, second instance is removed
WARNING:Xst:1988 - Unit <control>: instances <Mcompar__cmp_lt0000>,
<Mcompar__cmp_ge0000> of unit <LPM_COMPARE_1> and unit <LPM_COMPARE_4>
are dual, second instance is removed

Could someone please explain to me what this warning means? Can I
safely ignore it? I have followed the link for the warning code to the
Xilinx page, but it returns "page not found".

Thanks,

Mike

 

On Mar 11, 8:01 pm, Moikel <obviouslyadu...@gmail.com> wrote:

Hello,

Xilinx is giving me the following warning during synthesis:

=========================================================================
* Low Level
Synthesis *
=========================================================================
WARNING:Xst:1988 - Unit <control>: instances <Mcompar__cmp_lt0001>,
Mcompar__cmp_ge0001> of unit <LPM_COMPARE_1> and unit <LPM_COMPARE_4
are dual, second instance is removed
WARNING:Xst:1988 - Unit <control>: instances <Mcompar__cmp_lt0000>,
Mcompar__cmp_ge0000> of unit <LPM_COMPARE_1> and unit <LPM_COMPARE_4
are dual, second instance is removed

Could someone please explain to me what this warning means? Can I
safely ignore it? I have followed the link for the warning code to the
Xilinx page, but it returns "page not found".

Thanks,

Mike

Can't say for sure, but it looks like some intermediate stage in the
synthesizer decided to build a "less than" unit as well as a "greater
than or equal" unit, and the warning reflects its realization that, in
hardware, the two will always produce the opposite (i.e. dual) output,
hence it is replacing one of them with an inverter. My guess: this is
probably OK to ignore.

- Kenn

 

On Mar 11, 5:01 pm, Moikel <obviouslyadu...@gmail.com> wrote:

Hello,

Xilinx is giving me the following warning during synthesis:

=========================================================================
* Low Level
Synthesis *
=========================================================================
WARNING:Xst:1988 - Unit <control>: instances <Mcompar__cmp_lt0001>,
Mcompar__cmp_ge0001> of unit <LPM_COMPARE_1> and unit <LPM_COMPARE_4
are dual, second instance is removed
WARNING:Xst:1988 - Unit <control>: instances <Mcompar__cmp_lt0000>,
Mcompar__cmp_ge0000> of unit <LPM_COMPARE_1> and unit <LPM_COMPARE_4
are dual, second instance is removed

Could someone please explain to me what this warning means? Can I
safely ignore it? I have followed the link for the warning code to the
Xilinx page, but it returns "page not found".

Thanks,

Mike

To expand on what Kenn said:

XST has found something like this:

A = '1' when (B > C) else '0';
D = '0' when (C >= B) else '1';

Well, it turns out that 'A' and 'D' are the same, so it throws the 2nd
equation away (2nd instance is removed), and substitutes 'A' for every
'D'.

You can ignore these warnings. Unless you're expecting the two
signals to be different.

G.

 

[Symon]

"Thomas Reinemann" <tom.reinemann@gmx.net> wrote in message
news:fthus4$m11$1@news.boerde.de...

Hi,

usually we have statements like this kind, to copy the value of a signal.

pgen_data : process (sclk) is
begin -- process pgen_data
if rising_edge(sclk) then -- rising clock edge

sfifo_alt <= sfifo_data_in;

end if;
end process pgen_data;


To do it right, we have to figure out the type of the right value and
copy it. During debugging this can be time consuming and can led to
errors. Just my wish, the possibility to copy the type of a signal via
a certain keyword perhaps "copy_type".

Bye Tom

Hi Tom,
I think that by forcing the coder to specifically define the type of all
signals and to make them match, VHDL is aiding, not hindering, the debugging
process.
YMMV, Syms.

 

[HT-Lab]

"suresh" <babusuresh.achanta@gmail.com> wrote in message
news:7d07ed43-db93-409d-a4f2-c59af86aa37c@n14g2000pri.googlegroups.com...

Hi...

For 9.2i version, I have followed the following order to import the
unisim files.
unisim_VCOMP.vhd
unisim_VPKG.vhd
unisim_VITAL.vhd
unisim_SMODEL.vhd

But I am getting the error at compilation.

When I followed the same order for 9.1i version, it was compiling
successfully. Please help me about this.

thanks & regards,
Babu Suresh Achanta

If this is for Modelsim why not use Xilinx' compxlib?

Example (from a command shell, there is also a GUI version):

compxlib -w -s mti_pe -arch all -lib all -l all -verbose -dir
c:\vendors\mti_libs

Hans
www.ht-lab.com

 

[HT-Lab]

"suresh" <babusuresh.achanta@gmail.com> wrote in message
news:7d07ed43-db93-409d-a4f2-c59af86aa37c@n14g2000pri.googlegroups.com...

Hi...

For 9.2i version, I have followed the following order to import the
unisim files.
unisim_VCOMP.vhd
unisim_VPKG.vhd
unisim_VITAL.vhd
unisim_SMODEL.vhd

But I am getting the error at compilation.

When I followed the same order for 9.1i version, it was compiling
successfully. Please help me about this.

thanks & regards,
Babu Suresh Achanta

If this is for Modelsim why not use Xilinx' compxlib?

Example (from a command shell, there is also a GUI version):

compxlib -w -s mti_pe -arch all -lib all -l all -verbose -dir
c:\vendors\mti_libs

Hans
www.ht-lab.com