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 123550

Article: 123550
Subject: Re: bidirectional pin help
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 29 Aug 2007 22:58:55 -0400
Links: << >>  << T >>  << A >>
Zoran,

> somewhere on the board is 3.3V to 5.V converter, I didn't pay much
> attention about that. I'll have to look about that Although this thing
> obout this board and fpga is confusing, I have more wories about this
> warring that I am getting from the quartus. It clearly says that this
> pin constantly geting Vcc on it. I could bet that this is some
> problem, not on the board. Mybe on the fpga is some pull up resistor
> and it can't be turned off. I don't know what else could be.

I have looked at the board's schematics. There are tons of pullups to 5V, so
you probably are using one of these pins. How have you chosen your pins if
you have chosen them at all?

With regards to what Quartus says, I haven't touched Altera for quite a
number of years now, so I am not an expert here... Perhaps someone else
would be better equipped to answer why it is using open-drain output and
what exactly the warning means...

/Mikhail



Article: 123551
Subject: Re: bidirectional pin help
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 29 Aug 2007 23:06:09 -0400
Links: << >>  << T >>  << A >>
"MM" <mbmsv@yahoo.com> wrote in message
news:5jmq58FcbhqU1@mid.individual.net...
>
> With regards to what Quartus says, I haven't touched Altera for quite a
> number of years now, so I am not an expert here... Perhaps someone else
> would be better equipped to answer why it is using open-drain output and
> what exactly the warning means...
>
Actually after having read the warning one more time and having re-read what
Altera tech support guy told you I think I now understand what it all means.
VCC doesn't mean VCC, it means logic '1', and it is not applied to the pin
itself, it is applied to the datain port of the IO buffer, which happens to
be an open-drain buffer, and an Altera open-drain buffer when fed logic '1'
will have a transistor closed resulting high-impedance. So, I think
everything works as it should and the 5V measured results from an external
pullup resistor. Just study your schematics...

/Mikhail



Article: 123552
Subject: Xilinx FPGA Based Board Problem
From: Piyush Kaul <piyushkaul@gmail.com>
Date: Wed, 29 Aug 2007 21:04:23 -0700
Links: << >>  << T >>  << A >>
Hi All,

I am new to FPGAs and my main interest is implementation of some
signal processing algorithms on FPGAs. For testing the MEMEC  (DS-BD-
V2MB1000) board which has a xc2vc1000 fpga on it along with a xc18v04,
I was trying to write a simple module. I am using the impact Parallel
IV cable for download of my code.

I started with a simple VHDL code for a counter to be displayed on 7-
segment display. Since it did not work, I slowly started removing code
and now I have a single
line in the architecture

architecture board of testLed  is
begin
	led <= '1';
end board;

The "led" is the user led provided on the board.

Don't think it can get any simpler. But even this doesn't seem to
work. I am using the JTAG interface available on the board. The
boundary scan is working perfectly and detecting the FPGA & PROM.
After bypassing the PROM, I am loading the bit file on the FPGA.

I am using Xilinx ISE Foundation 6.2 & XST for synthesis and have also
assigned the pins through PACE. The edit contraints show the following
text.

NET "led" LOC = "A9"

Any suggestions regarding the possible cause of what I may be missing
will be welcome.

Regards
Piyush


Article: 123553
Subject: Re: Strange behaviour of a design
From: markus.jank@de.bosch.com
Date: Wed, 29 Aug 2007 22:45:10 -0700
Links: << >>  << T >>  << A >>
Good Morning,

thanks for your answers. I will try to do some timing verification
again.
But first here are the answers to your questions.

"Clarify please what kind of signal and how you change it."
=> I tried to insert status bits to make the states of the
     FSM visible with the oscilloscope.
=> Or use direct the states (coding by hand) to debug
     the FSM.

"...then the design doesn't function any more."
=> it seems that the state machine does not start. The start condition
depends only on one
input signal. This input signal is generated with a write with the DSP
to a register. With this
write a pulse of one clock cycle is generated that triggers the FSM.
The DSP is connected to the
FPGA with a synchronous interface.

What does it mean to "use direct routing"? How can I do that?
I did a lot post P&R simulations, but I can't see the error.

Markus



Article: 123554
Subject: Re: Xilinx / ISE multi-cycle path constraint pitfall
From: eli.billauer@gmail.com
Date: Thu, 30 Aug 2007 07:26:00 -0000
Links: << >>  << T >>  << A >>
On Aug 29, 2:10 pm, "Symon" <symon_bre...@hotmail.com> wrote:

> I think you've misinterpreted what's happening. In your original example,
> the 'cnt' signals don't need to get back to the clock enable input in one
> cycle. Only the signal 'en' does. As long as 'en' gets to the FFs in time,
> whatever the CNT signals are doing does not matter a jot.

I suggest that you (and all others who don't understand why I'm making
a fuss) take five minutes to try out the module I began with, along
with the corrected constraints I suggested for solution. Implement
this on the Xilinx tools, require a VERBOSE timing report, and go
through the paths belonging to "ts_no_multipath". (To make life
easier, I've copied them down at the end of this message)

These are the problematic paths, which arrive at the relevant flip-
flop's CE, and would be wrongly relaxed to four cycles, had it not
been for the correction.

And after making this correction on real-life designs I can tell you
that this is not a theoretic problem, even though I have to admit that
I've never experienced any FPGA malfunction which I could relate to
this.

But please, try this out.

     Eli

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

top.v follows:

module top(clk, cnt);


   input clk;
   output [15:0] cnt;


   reg [15:0]    cnt;
   reg [1:0]     en_counter;
   reg           en;


   always @(posedge clk)
     begin
        en_counter <= en_counter + 1;
        en <= (en_counter == 0);
     end


   always @(posedge clk)
     if (en) // This is the "clock enable"
       begin
          // This runs only once in four clocks
           if (cnt != 16'hffff)
           cnt <= cnt + 1;
       end


endmodule


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

top.ucf follows:

NET "clk" TNM_NET = "clk";
TIMESPEC "TS_clk" = PERIOD "clk" 10 ns HIGH 50 %;
NET "en" TNM = FFS "tgrp_en";
TIMESPEC "ts_multipath" = FROM "tgrp_en" TO "tgrp_en" "TS_clk" * 4;


PIN "*.CE" TPSYNC="tgrp_ces";
TIMESPEC "ts_no_multipath" = FROM "tgrp_en" TO "tgrp_ces" "TS_clk";


Article: 123555
Subject: Re: bidirectional pin help
From: Zorjak <Zorjak@gmail.com>
Date: Thu, 30 Aug 2007 07:27:45 -0000
Links: << >>  << T >>  << A >>
I thinks something is finaly clear to me:). You must be right. I mean,
it has to be it. When I was chosing my pins I didn't py much attention
about that. Actualy I just piked the first from one of this conectors.
I am now seeing this board and I am not shure how to eliminate this
pull up, if there is any chance to eliminate it. But now, I am almost
100% shure that this has to be it and nothing else.

Mikhail, Your help was raly great, and I can't say You, how much I am
thankful for all.
Zoran


MM wrote:
> "MM" <mbmsv@yahoo.com> wrote in message
> news:5jmq58FcbhqU1@mid.individual.net...
> >
> > With regards to what Quartus says, I haven't touched Altera for quite a
> > number of years now, so I am not an expert here... Perhaps someone else
> > would be better equipped to answer why it is using open-drain output and
> > what exactly the warning means...
> >
> Actually after having read the warning one more time and having re-read what
> Altera tech support guy told you I think I now understand what it all means.
> VCC doesn't mean VCC, it means logic '1', and it is not applied to the pin
> itself, it is applied to the datain port of the IO buffer, which happens to
> be an open-drain buffer, and an Altera open-drain buffer when fed logic '1'
> will have a transistor closed resulting high-impedance. So, I think
> everything works as it should and the 5V measured results from an external
> pullup resistor. Just study your schematics...
>
> /Mikhail


Article: 123556
Subject: Spartan3E and DDR termination
From: Guru <ales.gorkic@email.si>
Date: Thu, 30 Aug 2007 01:59:33 -0700
Links: << >>  << T >>  << A >>
Hi all,

We are building a board with Spartan3E (XC3S1200E FG320) and a 64MB
x16 DDR (HYB25DC512160CF-6). Trying to make the board as tiny as
possible the DDR termination presents a problem. Since the Spartan3E
does not have DCI, termination on chip is not possible. This means
that 44 termination resistors should be added and maybe a VTT power
source. The other problem is that according to MIG we should connect
DDR to two banks.

Any good suggestions?
Is it possible to eliminate termination resistors?

Cheers,

Guru


Article: 123557
Subject: modelsim
From: fazulu deen <fazulu.vlsi@gmail.com>
Date: Thu, 30 Aug 2007 02:21:14 -0700
Links: << >>  << T >>  << A >>
Hai all,

Can any one suggest with an example how to run c++ code in modelsim
simulator...I didnt understand the example mentioned in modelsim user
guide..Anyone tried this??

regards,
fazal


Article: 123558
Subject: Re: modelsim
From: Jon Beniston <jon@beniston.com>
Date: Thu, 30 Aug 2007 02:32:06 -0700
Links: << >>  << T >>  << A >>
On 30 Aug, 10:21, fazulu deen <fazulu.v...@gmail.com> wrote:
> Hai all,
>
> Can any one suggest with an example how to run c++ code in modelsim
> simulator...I didnt understand the example mentioned in modelsim user
> guide..Anyone tried this??

What didn't you understand about it?

Jon


Article: 123559
Subject: Re: Xilinx FPGA Based Board Problem
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Thu, 30 Aug 2007 10:57:38 +0100
Links: << >>  << T >>  << A >>
Piyush Kaul <piyushkaul@gmail.com> writes:

> Hi All,
>


 Hi Piyush,

>
> architecture board of testLed  is
> begin
> 	led <= '1';
> end board;
>
> The "led" is the user led provided on the board.
>
> Don't think it can get any simpler. But even this doesn't seem to
> work. I am using the JTAG interface available on the board. The
> boundary scan is working perfectly and detecting the FPGA & PROM.
> After bypassing the PROM, I am loading the bit file on the FPGA.
>
> I am using Xilinx ISE Foundation 6.2 & XST for synthesis and have also
> assigned the pins through PACE. The edit contraints show the following
> text.
>
> NET "led" LOC = "A9"
>

A few things come to mind...

I assume that *is* the right location?

Do you have the schematics for the board?  Sometimes the LEDs are
wired up so that they come on if the pin is *low*...

Do you know that the board works at all - have you got any pre-done
designs you could try on it?

Sorry not to have more specific ideas!

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 123560
Subject: Re: Xilinx / ISE multi-cycle path constraint pitfall
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 30 Aug 2007 11:22:18 +0100
Links: << >>  << T >>  << A >>
<eli.billauer@gmail.com> wrote in message 
news:1188458760.939432.256410@g4g2000hsf.googlegroups.com...
> On Aug 29, 2:10 pm, "Symon" <symon_bre...@hotmail.com> wrote:
>
>> I think you've misinterpreted what's happening. In your original example,
>> the 'cnt' signals don't need to get back to the clock enable input in one
>> cycle. Only the signal 'en' does. As long as 'en' gets to the FFs in 
>> time,
>> whatever the CNT signals are doing does not matter a jot.
>
> I suggest that you (and all others who don't understand why I'm making
> a fuss) take five minutes to try out the module I began with, along
> with the corrected constraints I suggested for solution. Implement
> this on the Xilinx tools, require a VERBOSE timing report, and go
> through the paths belonging to "ts_no_multipath". (To make life
> easier, I've copied them down at the end of this message)
>
> These are the problematic paths, which arrive at the relevant flip-
> flop's CE, and would be wrongly relaxed to four cycles, had it not
> been for the correction.
>
Hi Eli,
Of course, I think I DO understand why you're making a fuss, but think you 
don't need to worry! :-)

Please, instead of following your suggestion, let me spend the five minutes 
to allow me to try again to persuade you of the error of your ways!

You correctly state that the CNT signals have a logical path to the CE pin 
of the counter which generates them. Let's call the signal at this CE pin 
CNT_CE. This fact alone causes you to believe that these CNT signals must 
get through the logic which generates CNT_CE in one cycle.

However, this is _NOT_ true in this case. The signal EN, which is high for 
one in every four cycles of the clock, is gated into this logic that makes 
CNT_EN. Whenever EN is low, the signal CNT_CE is low, no matter what the CNT 
signals are. So, as long as the signal EN gets from the FF it's generated in 
to CNT_EN and the CE pins of the CNT counter, all will be well, provided the 
CNT signals get through the logic by the time the EN signal next goes high. 
Your original constraints are fine for your situation.

If this weren't the case, multi-cycle paths wouldn't work. Also, and I'm 
sure you realise this, there is nothing magical about the CE pin, it's just 
another logic input that controls a mux.

It's easy(ish) for you to try this out. I suggest that you (the person 
asking the group for input ;-)) get your simulator out, write your HDL to 
add suitable simulated long delays to the CNT pins, and see what happens. I 
only wish I'd pointed this out to you 2 weeks ago, I may have saved you some 
effort. My excuse is I didn't read the OP thoroughly as it seems to have 
Hebrew characters in it that my viewer complains about.

Finally, it is a pain in the arse when the synthesiser uses gated logic 
(that admittedly can save LUT usage) on the CE input if you have a very fast 
clock that needs clock enables. As I said in another post, Synplify has a 
switch called syn_direct_enable. This is great for fixing this problem.

In VHDL:-

attribute syn_direct_enable: boolean;
attribute syn_direct_enable of EN : signal is true;

HTH., Syms.



Article: 123561
Subject: Re: New keyword 'orif' and its implications
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: 30 Aug 2007 12:47:14 GMT
Links: << >>  << T >>  << A >>
On 2007-08-30, Weng Tianxiang <wtxwtx@gmail.com> wrote:

|---------------------------------------------------------------------------------------------|
|"On Aug 29, 3:44 pm, Andy <jonesa...@comcast.net> wrote:                                     |
|> On Aug 29, 11:46 am, Weng Tianxiang <wtx...@gmail.com> wrote:                              |
|>                                                                                            |
|>                                                                                            |
|>                                                                                            |
|>                                                                                            |
|>                                                                                            |
|> > On Aug 29, 3:13 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>                      |
|> > wrote:                                                                                   |
|>                                                                                            |
|[..]                                                                                         |
|> > > On 2007-08-28, Jim Lewis <j...@synthworks.com> wrote:                                  |
|[..]                                                                                         |
|>                                                                                            |
|> > > [..] I think the intention would be clearer with different                             |
|> > > indentation. [..]                                                                      |
|[..]                                                                                         |
|> > Hi Colin,                                                                                |
|> > Thank you for your support.                                                              |
|>                                                                                            |
|> > You are the first big canon who gave full support behind the keyword                     |
|> > 'orif' and gets full understanding of its meaning.                                       |
|---------------------------------------------------------------------------------------------|

Hello Weng,

I neither provided support for nor opposed your proposal, I simply
tried to clarify for Jim whether the appearances of elsif were typos.

I am indifferent.

However, you clearly have not understood any of the responses so far
in this thread. At least three alternatives not needing a new language
were shown to you:
a synthesis tool worth using should be able to determine how to
efficiently implement a design;
a case statement;
and
one-hot encoding or something similar using PSL instead of an
attribute.

The PSL approach is the only one you have tried to respond to. If you
can not prove that what you want to achieve can not be achieved
well otherwise, then you will find it difficult to convince people who
do not want too many ways to achieve one thing.

Your lack of appreciation for how the case statement is relevant and
other things you have revealed to us indicate that your depth of
understanding of VHDL needs to improve and this is also not helping
people to take you seriously. Please read at least two good books with
decent VHDL content, e.g. at least one of those listed on
WWW.Ashenden.com.Au
, and read the books you choose twice each.

|---------------------------------------------------------------------------------------------|
|"> > My fighting for 'orif' recognition is not for my personal purpose, it                   |
|> > is in the interest of HDL industry and academic world."                                  |
|[..]                                                                                         |
|> > 3. As keyword 'orif' definition says, 'orif' only provides information                   |
|> > about mutually exclusive property among a group of conditions.                           |
|> > Compilers can do what they think is the best strategy as they want.                      |
|> > But for FPGA, the 'orif' perfectly refers to carry chain structure in                    |
|> > both Xilinx and Altera (I am not familiar with other FPGA products),                     |
|> > it is a wonderful thing, but should not be a burden or a blame, as                       |
|> > Jonathan indicated.                                                                      |
|---------------------------------------------------------------------------------------------|

I appreciate that you are genuinely being noble, but please understand
that you should not insist that orif must be implemented as a carry
chain. The designer writes in a HDL and the optimizer in the synthesis
tool finds an efficient way to implement something. Something from a
HDL might not always be represented the same way, depending on many
issues too complicated to explain here. Please understand this example
from Andy:
|---------------------------------------------------------------------------------------------|
|"> Any synthesis tool that cannot figure out the code below (rewritten                       |
|> from your example, but in standard vhdl with elsif) indicates mutually                     |
|> exclusive conditions should be immediately uninstalled and returned to                     |
|> the vendor for a full refund!                                                              |
|>                                                                                            |
|> if(two_bits = "00") then                                                                   |
|>   ...                                                                                      |
|> elsif(two_bits = "01") then                                                                |
|>   ...                                                                                      |
|> elsif(two_bits = "10") then                                                                |
|>   ...                                                                                      |
|> else  <-- equivalent to "when others =>"                                                   |
|>   ...                                                                                      |
|> end if;"                                                                                   |
|---------------------------------------------------------------------------------------------|

No matter how you improve your proposal for orif, you can not refute
this point of Andy's.

Weng posted:

|---------------------------------------------------------------------------------------------|
|"> > > On 2007-08-28, Jim Lewis <j...@synthworks.com> wrote:                                 |
|[..]                                                                                         |
|>                                                                                            |
|> > > |--------------------------------------------------------------------------ญญ|         |
|> > > |"[..]                                                                     |           |
|> > > |                                                                          |           |
|> > > |[..]  The danger in adding new keywords is that they may                  |           |
|> > > |conflict with a name (signal, ...) already used in someone's design       |           |
|> > > |and cause an old design to be a syntax error in the new language          |           |
|> > > |revision.  This generally does not please people and means they           |           |
|> > > |have to add special handling for the file (compile flags).                |           |
|> > > |                                                                          |           |
|> > > |[..]"                                                                     |           |
|> > > |--------------------------------------------------------------------------ญญ|         |
|>                                                                                            |
|> > > A newly introduced reserved word would be guaranteed to not conflict                   |
|> > > with old code by not being possible to misinterpret as a basic                         |
|> > > identifier (basic_identifier ::= letter { [ underline ]                                |
|> > > letter_or_digit), e.g. by starting with an underline or by containing                  |
|> > > a percentage sign.                                                                     |
|>                                                                                            |
|> > > Best regards,                                                                          |
|> > > Colin Paul                                                                             |
|[..]                                                                                         |
|> > 3. "A newly introduced reserved word would be guaranteed to not                          |
|> > conflict                                                                                 |
|> > with old code"                                                                           |
|>                                                                                            |
|> > Jim's opinion is that if you introduce a new keyword 'orif', then even                   |
|> > though 'orif' doesn't conflict with 'elsif', but it certainly would                      |
|> > conflict with old signal name orif. This can never be avoided."                          |
|---------------------------------------------------------------------------------------------|

This can easily be avoided as I had already showed: it would be legal
and easy to have a reserved word (e.g. _orif) which could never had
been used as a basic_identifier.

|---------------------------------------------------------------------------------------------|
|" But his                                                                                    |
|> > new function name zero_one_hot() still has the same possibility to                       |
|> > conflict with old signal function name zero_one_hot() if someone had                     |
|> > used it before, but he never mentioned his same possibility.                             |
|---------------------------------------------------------------------------------------------|

That would be true for plain VHDL without PSL, but he posted as if
zero_one_hot() is now part of VHDL from PSL (but it is not in my PSL
reference manual, unlike onehot0) so that would not necessarily
require that a VHDL identifier be changed. From the PSL standard:
"[..]

4.2.2 Keywords
Keywords are reserved identifiers in PSL, so an HDL name that is a PSL
keyword cannot be referenced
directly, by its simple name, in an HDL expression used in a PSL
property. However, such an HDL name can
be referenced indirectly, using a hierarchical name or qualified name
as allowed by the underlying HDL.
The keywords used in PSL are shown in Table 1.
[..]
onehot0
[..]
5.2.3 Built-in functions
PSL defines a collection of built-in functions that detect typically
interesting conditions, or compute useful
values, as shown in Syntax 5-20.
Syntax 5-20.Built-in functions
HDL_or_PSL_Expression ::=
PSL_Expression
PSL_Expression ::=
Boolean -> Boolean
| Boolean <-> Boolean
Built_In_Function_Call ::=
prev (Any_Type [ , Number [ , Clock_Expression ]] )
[..]
| onehot0 ( BitVector )
[..]"

|---------------------------------------------------------------------------------------------|
|"> The fact that orif must be indented from elsif, is a very poor way to                     |
|> indicate functional structure of code. [..]"                                               |
|---------------------------------------------------------------------------------------------|

Andy,

Your example
enable := (others => '0');
for i in enable'range loop
  if address = i then
    enable(i) := '1';
  end if;
end loop;
from news:1188329351.852738.51270@22g2000hsm.googlegroups.com is
easier to read with indentation than
enable := (others => '0');
for i in enable'range loop if address = i then enable(i) := '1'; end if; end loop;
and is condemning evidence against neither FOR nor IF.

|---------------------------------------------------------------------------------------------|
|"[..]                                                                                        |
|> zero_one_hot() can always be prefixed with the standard package name                       |
|> in which it is defined."                                                                   |
|---------------------------------------------------------------------------------------------|

Andy,

Is zero_one_hot() defined in a package? Even if it is, Weng was
complaining that Jim complained that orif would clash with a
basic_identifier and Weng perceived this as hypocrisy as he thought
zero_one_hot() would also clash with a basic_identifier.

|---------------------------------------------------------------------------------------------|
|" Keywords, on the other hand cannot. I believe                                              |
|> that tricks like '_' and '%' on the front of new keywords are a                            |
|> hideous hack, [..]                                                                         |
|---------------------------------------------------------------------------------------------|

Actually _ would need to go to the front but % could go anywhere, not
that this would make you detest the ways in which new reserved words
can be added to VHDL (sorry to Verilog people reading this) with a
guarantee that old basic_identifiers will still be valid.

|---------------------------------------------------------------------------------------------|
|"[..]                                                                                        |
|                                                                                             |
|I can imagine if both methods, Jim's and mine, are introduced into                           |
|VHDL standard, I can bet with you: 99.9999% of engineers who use                             |
|mutually exclusive method to speed up their designs would use my                             |
|method. My basis is nobody who write 'if...eslif...end if' statements                        |
|today uses 2 separate parts as Jim suggested for zero_one_hot() to                           |
|write 'if...eslif...end if' statements.                                                      |
|                                                                                             |
|[..]"                                                                                        |
|---------------------------------------------------------------------------------------------|

Does the way that most reactions you have received are negative not
seem to indicate that maybe 99.9999% adoption of your proposal is
overly optimistic? It could be said that almost 99.9999% of people who
write in VHDL write the basic_identifier for detecting a clock edge
with "2 separate parts" even though a standard to use the
basic_identifier only once per detection was published alongside
VHDL93.

Regards,
Colin Paul

P.S. This thread is taking up a lot of time, I might not post denials
of mischaracterizations of me again until many days later as I need to
get other work done soon.

Article: 123562
Subject: Re: modelsim
From: fazulu deen <fazulu.vlsi@gmail.com>
Date: Thu, 30 Aug 2007 06:00:35 -0700
Links: << >>  << T >>  << A >>

Jon Beniston wrote:
> On 30 Aug, 10:21, fazulu deen <fazulu.v...@gmail.com> wrote:
> > Hai all,
> >
> > Can any one suggest with an example how to run c++ code in modelsim
> > simulator...I didnt understand the example mentioned in modelsim user
> > guide..Anyone tried this??
>
> What didn't you understand about it?
>
>linking was not clear to me and also in my case while simulating the c++ it will output a test file that has be red by the verilog code...both c++ and verilog is independent and c++ should be first before verilog after the file is obtained from the c++ simulator the verilog will start....how this can be achieved


Article: 123563
Subject: Re: Where is Command Reg and Status Reg as mentioned in PCI system architecture (Mindshare) in generated pci32 core?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 30 Aug 2007 14:02:23 +0100
Links: << >>  << T >>  << A >>
On Wed, 29 Aug 2007 18:54:31 -0700, Ace <yasirmm@gmail.com> wrote:

>Hi,
>
>I realize that in cfg.vhd files generated by PCI32 LogiCore does not
>have command register and status register. From Mindshare book, it
>said it is "always mandatory" to supply this information. Does anyone
>know what do I need to do/add?

I don't believe you have to add anything; they are automatically there.

If you look at the "signal description" section of the "implementation"
PDF you will see a description of the command register bits made
available to the user interface. This confirms that the register
exists...

You do need to use a configuration cycle to write to the command
register to enable memory or I/O transfers when initialising the core;
see "stimulus.vhd" in the ping_tb testbench for example.

- Brian

Article: 123564
Subject: Spartan 3E starter kit (Rev.D) modification : 3E500 -> 3E1200
From: dormanpeter1@gmail.com
Date: Thu, 30 Aug 2007 13:14:51 -0000
Links: << >>  << T >>  << A >>
Hello!

I would like to change the FPGA in this board to a bigger one, but I
don't know if it's possible.
I noticed in the datasheet ( http://direct.xilinx.com/bvdocs/publications/ds312.pdf
) that the 500 and 1200 versions are pin compatible (FG320), so my
question would be whether it is enough to simple change it out, or I
have to do something more with it?
(The 4 Mbit platform flash on the board is enough for configuration;
but if I would like to have a S3E1600, I would need 8 Mbit p.f.)
I can see some smd capacitors next to the fpga, quite close... are
they to survive the soldering process, or will I have to buy new ones,
and solder them there?


Article: 123565
Subject: Re: New Xilinx forum.
From: Gabor <gabor@alacron.com>
Date: Thu, 30 Aug 2007 06:29:12 -0700
Links: << >>  << T >>  << A >>
The new xilinx forum now has a recent threads link.  IMHO
this makes the forum much more useful for contributors...

http://forums.xilinx.com/xlnx/newthreads


Article: 123566
Subject: Re: Partial reconfiguration using ICAP
From: Neil Steiner <neil.steiner@vt.edu>
Date: Thu, 30 Aug 2007 09:36:12 -0400
Links: << >>  << T >>  << A >>
> 1. So when i try doing this the program is not completely get written
> and gets hanged in between. But when i generated raw bit files (using
> - b option in bitgen) i am able to transfer the whole content , but
> after downloading, the system is not functioning as expected ( no
> change in the display).
> The other thing is that the size of original .bit file is 158kB,
> and .rbt file is 1356kB - so what makes the .rbt fle so big.

I may have steered you wrong when I mentioned raw bitstreams; the 
terminology is sometimes misleading.  The bitgen -b (Create Rawbits 
File) is *not* what you want, so the fact that the .rbt is enormous is 
irrelevant.

> 2. I tried downloading .bin file (generated using - g binary : yes
> option in bitgen)  again the whole data is not getting transfered but
> gets stuck up in between. but the size of this file is only 157kB with
> header removed.

The -b binary:yes option is indeed what you want, because it generates a 
regular bitstream without the human-readable header.  The fact that the 
regular .bit and the binary .bin are nearly identical in size makes sense.

So the question now is why the .bin download is not working correctly.

The first thing I would do is try to download the .bit file to the board 
from iMPACT, as Sean suggested.  You absolutely should get the correct 
results when you try that, and if you do not, you will have to verify 
that your design really does what it's supposed to do.

Once you've verified that the .bit works correctly from iMPACT, you'll 
need to figure out why the .bin does not work correctly from your 
PowerPC code.  Until you are able to feed the bitstream through the ICAP 
with no errors, you shouldn't expect the design to work.  A few things 
to be aware of on that point:

- Read 
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/02e00d4ec0ef783e 
if you have not already done so.  You can either correct 
XhwIcap_SetConfiguration(), or you can call a modified version of it.

- Overwriting configuration frames that touch LUT RAM (including shift 
registers) or dual-ported BRAM resources can do Undefined Things.  Which 
is to say that you could be killing your design unintentionally.  (But 
perhaps PlanAhead protects against that; I'm not really sure since I 
don't use PlanAhead.)  It's somewhat unlikely that this is the source of 
your problems, but it is possible.

Furthermore, you may have to do what many of us do when approaching a 
new problem:  Take a ridiculously simple design and try to debug it 
first.  Driving an LED high or low is a time-tested favorite.

Article: 123567
Subject: Re: Spartan3E and DDR termination
From: Gabor <gabor@alacron.com>
Date: Thu, 30 Aug 2007 06:41:25 -0700
Links: << >>  << T >>  << A >>
On Aug 30, 4:59 am, Guru <ales.gor...@email.si> wrote:
> Hi all,
>
> We are building a board with Spartan3E (XC3S1200E FG320) and a 64MB
> x16 DDR (HYB25DC512160CF-6). Trying to make the board as tiny as
> possible the DDR termination presents a problem. Since the Spartan3E
> does not have DCI, termination on chip is not possible. This means
> that 44 termination resistors should be added and maybe a VTT power
> source. The other problem is that according to MIG we should connect
> DDR to two banks.
>
> Any good suggestions?
> Is it possible to eliminate termination resistors?
>
> Cheers,
>
> Guru


If you're only driving a single chip with very short lines you
can probably get away without termination on everything except
the clock.  I would suggest using SSTL2_I instead of SSTL2_II
to avoid overdriving.  Another approach is to just leave out
the series termination on these signals and just add the parallel
termination to Vtt.  I've used the latter method with Virtex2
and an SO-DIMM without DCI on the data lines and SSTL2_I drive.
A good argument for leaving out the series termination is any
net where the driving stub (from the S3 to the resistor) is
about the same length as the driven stub (from the resistor
to the memory).  Here the terminator is of dubious value.

It's probably best to simulate your transmission lines,
especially if you're planning to run the memory at its
maximum speed of 166 MHz / DDR333.  My V2 design ran at
133 MHz / DDR266.

HTH,
Gabor


Article: 123568
Subject: Re: Strange behaviour of a design
From: Gabor <gabor@alacron.com>
Date: Thu, 30 Aug 2007 06:48:58 -0700
Links: << >>  << T >>  << A >>
On Aug 30, 1:45 am, markus.j...@de.bosch.com wrote:
> Good Morning,
>
> thanks for your answers. I will try to do some timing verification
> again.
> But first here are the answers to your questions.
>
> "Clarify please what kind of signal and how you change it."
> => I tried to insert status bits to make the states of the
>      FSM visible with the oscilloscope.
> => Or use direct the states (coding by hand) to debug
>      the FSM.
>
> "...then the design doesn't function any more."
> => it seems that the state machine does not start. The start condition
> depends only on one
> input signal. This input signal is generated with a write with the DSP
> to a register. With this
> write a pulse of one clock cycle is generated that triggers the FSM.
> The DSP is connected to the
> FPGA with a synchronous interface.
>
> What does it mean to "use direct routing"? How can I do that?
> I did a lot post P&R simulations, but I can't see the error.
>
> Markus


You haven't mentioned which part and tools you're using.  Xilinx?
Altera?  The DSP is off-chip?  Perhaps the "synchronous interface"
isn't meeting input setup and hold requirements?

Another thought is FSM implementation.  In Xilinx tools you have
to work very hard to force the implementation to use anything other
than one-hot encoding.  This has the unfortunate habit of going
"zero-hot" when inputs are not properly synchronized.  Bringing
the state bit out to debug pins could possibly cause the FSM
encoding to change, masking your problem.

HTH,
Gabor


Article: 123569
Subject: PCB Impedance Control
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Thu, 30 Aug 2007 08:55:17 -0500
Links: << >>  << T >>  << A >>

Hi

If I am designing a pcb using impedance controlled layers can I treat the
power planes as a reference layer as well as the gnd layers?

Cheers

Jon

Article: 123570
Subject: Re: Output signals not synchronized
From: Gabor <gabor@alacron.com>
Date: Thu, 30 Aug 2007 06:58:59 -0700
Links: << >>  << T >>  << A >>
On Aug 29, 7:40 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
> "EEngineer" <mari...@gmail.com> wrote in message
>
> news:1188426999.764557.233750@k79g2000hse.googlegroups.com...
>
> > there are also UCF lines:
>
> > NET ctrl_data<*> SLEW = FAST;
> > NET ctrl_data<*> DRIVE = 2;
> > NET ctrl_data<*> IOSTANDARD = LVCMOS33;
>
> To start with, your timing constraint of OFFSET = OUT 100 ps AFTER is not
> something that will make your outputs happen coincident with your clock,
> it's a specification that will simply fail in the place & route and timing
> analyzer.  Take a look.  The fastest your outputs will go depend on how fast
> an IOB register can deliver its output relative to your global clock.  These
> numbers are documented and easy to prototype.
>
> Second, the 2 mA drive level will give you a slower rise/fall.  The skew in
> your output signal time can - depending on your load - be a noticeable time
> difference.
>
> Third, the logic analyzer is an asynchronous device which will usually
> provide a 2.5 ns uncertainty in your results leaving only a 2.5 ns
> difference not explained by the test equipment.
>
> Please find the online documentation (or a Xilinx class) that describes what
> you can and cannot do with constraints.  This fundamental information
> usually is only understood after an engineer can't understand why their
> design isn't working.  Learn it.

If you need your outputs to have very low skew, your only hope
is to place all of the output flip-flops in the IOB's (IOB=TRUE
attribute on the flip-flop or net).  You can also globally place
registers in IOB's using the synthesis and map properties.  If
your outputs are generated by fabric flip-flops it is very hard
to get your skew below 2.5 nS

By the way, why do you need such low skew on these lines?  Is the
driven device asynchronous with respect to your clock?

Regards,
Gabor


Article: 123571
Subject: Re: Output signals not synchronized
From: s.stanislava@gmail.com
Date: Thu, 30 Aug 2007 14:12:40 -0000
Links: << >>  << T >>  << A >>
On Aug 30, 9:58 am, Gabor <ga...@alacron.com> wrote:
> On Aug 29, 7:40 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
>
>
>
> > "EEngineer" <mari...@gmail.com> wrote in message
>
> >news:1188426999.764557.233750@k79g2000hse.googlegroups.com...
>
> > > there are also UCF lines:
>
> > > NET ctrl_data<*> SLEW = FAST;
> > > NET ctrl_data<*> DRIVE = 2;
> > > NET ctrl_data<*> IOSTANDARD = LVCMOS33;
>
> > To start with, your timing constraint of OFFSET = OUT 100 ps AFTER is not
> > something that will make your outputs happen coincident with your clock,
> > it's a specification that will simply fail in the place & route and timing
> > analyzer.  Take a look.  The fastest your outputs will go depend on how fast
> > an IOB register can deliver its output relative to your global clock.  These
> > numbers are documented and easy to prototype.
>
> > Second, the 2 mA drive level will give you a slower rise/fall.  The skew in
> > your output signal time can - depending on your load - be a noticeable time
> > difference.
>
> > Third, the logic analyzer is an asynchronous device which will usually
> > provide a 2.5 ns uncertainty in your results leaving only a 2.5 ns
> > difference not explained by the test equipment.
>
> > Please find the online documentation (or a Xilinx class) that describes what
> > you can and cannot do with constraints.  This fundamental information
> > usually is only understood after an engineer can't understand why their
> > design isn't working.  Learn it.
>
> If you need your outputs to have very low skew, your only hope
> is to place all of the output flip-flops in the IOB's (IOB=TRUE
> attribute on the flip-flop or net).  You can also globally place
> registers in IOB's using the synthesis and map properties.  If
> your outputs are generated by fabric flip-flops it is very hard
> to get your skew below 2.5 nS
>
> By the way, why do you need such low skew on these lines?  Is the
> driven device asynchronous with respect to your clock?
>
> Regards,
> Gabor

I need those signals to control the analog CMOS circuit that has a
requirement for some signals not to overlap - this happens when the
output from the FPGA is not synchronous enough.


Article: 123572
Subject: Re: Output signals not synchronized
From: EEngineer <maricic@gmail.com>
Date: Thu, 30 Aug 2007 14:14:35 -0000
Links: << >>  << T >>  << A >>
On Aug 30, 9:58 am, Gabor <ga...@alacron.com> wrote:
> On Aug 29, 7:40 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
>
>
>
> > "EEngineer" <mari...@gmail.com> wrote in message
>
> >news:1188426999.764557.233750@k79g2000hse.googlegroups.com...
>
> > > there are also UCF lines:
>
> > > NET ctrl_data<*> SLEW = FAST;
> > > NET ctrl_data<*> DRIVE = 2;
> > > NET ctrl_data<*> IOSTANDARD = LVCMOS33;
>
> > To start with, your timing constraint of OFFSET = OUT 100 ps AFTER is not
> > something that will make your outputs happen coincident with your clock,
> > it's a specification that will simply fail in the place & route and timing
> > analyzer.  Take a look.  The fastest your outputs will go depend on how fast
> > an IOB register can deliver its output relative to your global clock.  These
> > numbers are documented and easy to prototype.
>
> > Second, the 2 mA drive level will give you a slower rise/fall.  The skew in
> > your output signal time can - depending on your load - be a noticeable time
> > difference.
>
> > Third, the logic analyzer is an asynchronous device which will usually
> > provide a 2.5 ns uncertainty in your results leaving only a 2.5 ns
> > difference not explained by the test equipment.
>
> > Please find the online documentation (or a Xilinx class) that describes what
> > you can and cannot do with constraints.  This fundamental information
> > usually is only understood after an engineer can't understand why their
> > design isn't working.  Learn it.
>
> If you need your outputs to have very low skew, your only hope
> is to place all of the output flip-flops in the IOB's (IOB=TRUE
> attribute on the flip-flop or net).  You can also globally place
> registers in IOB's using the synthesis and map properties.  If
> your outputs are generated by fabric flip-flops it is very hard
> to get your skew below 2.5 nS
>
> By the way, why do you need such low skew on these lines?  Is the
> driven device asynchronous with respect to your clock?
>
> Regards,
> Gabor

I need those signals to control the analog CMOS circuit that has a
requirement for some signals not to overlap - this happens when the
output from the FPGA is not synchronous enough.


Article: 123573
Subject: Re: Spartan 3E starter kit (Rev.D) modification : 3E500 -> 3E1200
From: emu <emu@ecubics.com>
Date: Thu, 30 Aug 2007 07:20:48 -0700
Links: << >>  << T >>  << A >>
On Aug 30, 7:14 am, dormanpet...@gmail.com wrote:
> Hello!
>
> I would like to change the FPGA in this board to a bigger one, but I
> don't know if it's possible.

Why are you not just buying the bigger one with the xc3s1600e ?



Article: 123574
Subject: Re: New keyword 'orif' and its implications
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: Thu, 30 Aug 2007 14:28:47 -0000
Links: << >>  << T >>  << A >>
On 28 Aug., 13:23, Marcus Harnisch <marcus.harni...@gmx.net> wrote:
> Weng Tianxiang <wtx...@gmail.com> writes:
Weng, take a step back.

First, not under all circumstances the carry chain implementation is
the most efficient of the gated OR selector.
For small number of inputs it fits into a single 6-LUT, for very large
number of inputs the logarithmic delay of the tree will be better than
the linear delay of the carry chain, even though the constants for the
carry chain are better.

Second, the only thing that your orif keyword thos, is a hint to the
synthesizer that the behaviour is undefined for certain input
combinations. You restrict the domain of the function. The following
code has the same semantics:


if E1 + E2 + E3 > 1 then -- (Lazy and incorrect VHDL type handling to
shorten example, you will get the point)
  result <= (others => '-');
elsif E1 = '1' then
  result <= input1;
elsif E2 = '1' then
  result <= input2;
elsif E3 = '1' then
  result <= input3;
else
  result <= (others => '0');
end if;

You will however notice, that most synthesis tools will not utilize
the optimization potential available from '-'.
I am often annoyed by this. For example if you write an instruction
decoder for a CPU, you do not care about the behaviour of the ALU for
all instructions that use no ALU result. Specifying don't cares would
greatly reduce the amount of logic for the decoder. This is an
improvement that is far more versatile than your proposal and it is
allready in the language.

However most synthesis tools will replace all occurences of '-' with
'0'. The reason behind this is that verification guys hate don't
cares. For regression testing you wan't the hardware to behave the
same if the specification did not change. '-' might be synthesized
differently every time. For formal verification you definitely can't
allow the freedom of don't cares.
In most contexts verification is a far bigger problem then efficient
implementation.

If you really want the most efficient implemetation you should specify
the detailed behaviour.

assert (PSL formulation to guarentee mutual exclusiveness goes here);
result <= (input1 and (result'range => E1) or (input2 and
(result'range => E2) or (input3 and (result'range => E3);

Telling the synthesis tool to implement wide ORs in carry chains is
simpler than to introduce a new keyboard.
This way other uses of wide ORs benefit aswell, as do users of other
languages.

Kolja Sulimma

P.S.: Xilinx has a patent on implementing a wide OR using carry logic.
There is no explicit license that grants you the right to distribute
bitstreams that use that trick. Xilinx says, they do not want to sue
anybody about that. But I bet Unisys had no intent to sue GIF users in
the 80ies. But intentions can change. Do you want to bet your business
on an informal declaration by Austin in a newsgroup?





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