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 123625

Article: 123625
Subject: Re: Spartan3E and DDR termination
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 31 Aug 2007 13:31:20 +0100
Links: << >>  << T >>  << A >>
On Thu, 30 Aug 2007 01:59:33 -0700, Guru <ales.gorkic@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?

As Gabor suggests, it may be possible to eliminate the series
terminations if traces are kept short enough.

If you also want to eliminate the parallel terminations to VTT, consider
moving to DDR-II, where you can use the On-Die Termination (ODT)
instead. It means a little extra design complexity, and 1.8V supplies,
but if space is important enough it may be worth considering.

- Brian

Article: 123626
Subject: Re: PCB Impedance Control
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 31 Aug 2007 13:38:11 +0100
Links: << >>  << T >>  << A >>
On Fri, 31 Aug 2007 11:02:13 +0100, "Symon" <symon_brewer@hotmail.com>
wrote:

>"John_H" <newsgroup@johnhandwork.com> wrote in message 
>news:13de6b5q88e3ke1@corp.supernews.com...
>> "PeteS" <axkz70@dsl.pipex.com> wrote in message 
>> news:H-ydnSZMEttzlkrbnZ2dnUVZ8vidnZ2d@pipex.net...
>> <snip>
>>>
>>> I have a number of pretty pics I made to illustrate the issue. I'll put 
>>> 'em on a.b.s.e tomorrow sometime.
>>>
>>> As an aside, at high speeds (which I define as having a track longer than 
>>> 1/4 rising/falling edge, YMMVG), there is no such thing as 'ground'. The 
>>> ground plane is a signal layer insulated by copper ;)
>>> [Although it helps to keep large power currents away from the high speed 
>>> return paths].
>>>
>>> Cheers
>>>
>>> PeteS
>>
>> Since without a ground one has a dipole antenna, could you qualify what 
>> you mean?  The impedance of the plane is measured in units of picoHenry 
>> per square so it's not a solid ground, certainly, but without a ground 
>> we'd be in a world of hurt at these high frequencies.
>>
>I think Pete means that at high frequencies the skin effect means that the 
>current in the plane is all on one surface of the plane. Thus the bulk of 
>the plane might as well be an insulator. Or something like that?

I think he means the return current is mostly localised directly under
the signal track; the copper under the "space" between tracks carries
relatively little current and could *almost* be replaced by insulator. 

- Brian


Article: 123627
Subject: Is it possible to make bit files generated by Xilinx ISE readable?
From: Wei Wang <camwwang@gmail.com>
Date: Fri, 31 Aug 2007 06:38:31 -0700
Links: << >>  << T >>  << A >>
I thought the bit files generated by Xilinx ISE should be in plain
binary format, but actually the .bit file is unreadable when opened in
XEmacs, just wondering whether it is possible to make these bit files
readable? Many thanks, -Wei


Article: 123628
Subject: Wifi with a Virtex 4
From: Peter Mendham <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk>
Date: Fri, 31 Aug 2007 14:47:03 +0100
Links: << >>  << T >>  << A >>
Dear all,

I'm just starting to look into the possibility of adding 802.11g to one 
of our products which is based on a Virtex 4 FX.  Does anyone have any 
experience with this?  Is there 802.11g MAC IP available?  Are there any 
suitable dev boards?  Is the best way to do it to use a COTS product 
like a CF card or similar?  Any suggestions/experience would be great.

TIA,
-- Peter

Article: 123629
Subject: Re: Is it possible to make bit files generated by Xilinx ISE readable?
From: John_H <newsgroup@johnhandwork.com>
Date: Fri, 31 Aug 2007 14:07:57 GMT
Links: << >>  << T >>  << A >>
Wei Wang wrote:
> I thought the bit files generated by Xilinx ISE should be in plain
> binary format, but actually the .bit file is unreadable when opened in
> XEmacs, just wondering whether it is possible to make these bit files
> readable? Many thanks, -Wei
> 

You can generate .rbt files that are ASCII ones and zeros, .mcs files 
that are formatted for programmers... take a look at the options in bitgen.

Article: 123630
Subject: Re: New keyword 'orif' and its implications
From: Andy <jonesandy@comcast.net>
Date: Fri, 31 Aug 2007 07:29:53 -0700
Links: << >>  << T >>  << A >>
Weng,

You're right, the loop code example is a good example. It beautifully
illustrates the fatal flaw in 'orif': it cannot be applied to an
arbitrary (parameterized) number of conditions. You still have not
acknowledged this flaw.

As for "extra" declarations and assignments, I took YOUR example that
had separate signals for E0, E1... E5, (which must have been declared
and assigned separately somewhere else), and simply combined them into
an array (with one fifth the signal declarations). Likewise I took
YOUR data0, data1...data5 signals (which also must have been declared
and assigned somewhere else), and combined them, with a similar
SAVINGS in declarations. So, tell me again how it would take more code
to use the arrays that it did the separate signals?

This is one of my biggest pet peeves when I see others' code that has
signals named the same, with incrementing suffixes: Use an array, and
once it is in an array, use a loop. It takes less code, not more, to
use an array.

As for your later example:

assert zero_one_hot(((TWindowLoad_E0_L_H and nC_BE_R0(3) = '0'),
    (TWindowLoad_E0_H_H and nC_BE_R0(7) = '0')));

I simply cut and pasted the expressions that were deemed mutually
exclusive from your code. Not a lot of typing going on there.

If, on the other hand I wanted your original code to be a little more
readable, I might have declared/assigned a signal/variable or two,
aptly named, to represent the conditions in a more human readable
form. Then those same signals and variables could be used in the
asserted function call as well. Yes, a little more code, but a little
more readable too.

I don't know about everyone else, but I don't want VHDL to look like
Verilog! Verilog does some really stupid things, and I don't want us
jumping off the same cliff they just did.

Take a closer look at that (System?)Verilog code. They started out
with an array (E) filled with random values, and then broke it back
out into discrete signals to use in the 'if' tree (could they have
just used elements of E?). All because they can't use 'unique' in a
loop! That is a fantastic example of the folly of unique/orif! Thanks!

Andy


Article: 123631
Subject: Re: PCB Impedance Control
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Fri, 31 Aug 2007 07:30:29 -0700
Links: << >>  << T >>  << A >>
Hi - 

On Fri, 31 Aug 2007 13:38:11 +0100, Brian Drummond
<brian_drummond@btconnect.com> wrote:

>On Fri, 31 Aug 2007 11:02:13 +0100, "Symon" <symon_brewer@hotmail.com>
>wrote:
>
>>"John_H" <newsgroup@johnhandwork.com> wrote in message 
>>news:13de6b5q88e3ke1@corp.supernews.com...
>>> "PeteS" <axkz70@dsl.pipex.com> wrote in message 
>>> news:H-ydnSZMEttzlkrbnZ2dnUVZ8vidnZ2d@pipex.net...
>>> <snip>
>>>>
>>>> I have a number of pretty pics I made to illustrate the issue. I'll put 
>>>> 'em on a.b.s.e tomorrow sometime.
>>>>
>>>> As an aside, at high speeds (which I define as having a track longer than 
>>>> 1/4 rising/falling edge, YMMVG), there is no such thing as 'ground'. The 
>>>> ground plane is a signal layer insulated by copper ;)
>>>> [Although it helps to keep large power currents away from the high speed 
>>>> return paths].
>>>>
>>>> Cheers
>>>>
>>>> PeteS
>>>
>>> Since without a ground one has a dipole antenna, could you qualify what 
>>> you mean?  The impedance of the plane is measured in units of picoHenry 
>>> per square so it's not a solid ground, certainly, but without a ground 
>>> we'd be in a world of hurt at these high frequencies.
>>>
>>I think Pete means that at high frequencies the skin effect means that the 
>>current in the plane is all on one surface of the plane. Thus the bulk of 
>>the plane might as well be an insulator. Or something like that?
>
>I think he means the return current is mostly localised directly under
>the signal track; the copper under the "space" between tracks carries
>relatively little current and could *almost* be replaced by insulator. 
>
>- Brian

Seems to me you're both right: the return current is bunched up under
trace, on the side of the ground plane adjacent to the trace.  This
"path" is surrounded by copper.  To paraphrase Doug Smith, a local EMC
consultant, the other side of the plane might as well be on the moon.

Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com

Article: 123632
Subject: Memory bandwidth of the 3A kit
From: Simon <google@gornall.net>
Date: Fri, 31 Aug 2007 14:39:34 -0000
Links: << >>  << T >>  << A >>
Antti, did you ever get a feel for what memory bandwidth you actually
get with this setup ? For example, if you had a blockram being
constantly filled from DDR2 ram, how many MB/sec you can actually pull
over the bus ?

Wondering whether to buy (yet another) starterkit ... [grin]

Cheers,
   S.


Article: 123633
Subject: Re: Xilinx FPGA Based Board Problem
From: SKatsyuba@gmail.com
Date: Fri, 31 Aug 2007 07:40:19 -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

Try to light the led with a boundary-scan software like Scanseer
(http://www.scanseer). Put your FPGA in EXTEST mode and manipulate
with its pins' signals. This way you can check PCB interconnections.


Article: 123634
Subject: Re: New keyword 'orif' and its implications
From: Andy <jonesandy@comcast.net>
Date: Fri, 31 Aug 2007 07:59:42 -0700
Links: << >>  << T >>  << A >>
On Aug 30, 10:32 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> Hi Jim and Colin,
> Your assert zero_one_hot() (or any other function name) may not be the
> one I want.
>
> Your zero_one_hot() tells simulator to check if all bits meet the zero
> or one active conditions. If it meets, return '1', otherwise return
> '0'.
>
> The code doesn't have any AUTHORITY to let VHDL compiler to do any
> optimization, and it just has the AUTHORITY to let simulator run the
> function and check its correctness.
>
> An assertion function is not authorized to transfer information to
> VHDL compiler !
>
> In strict computer language meaning, any VHDL compiler has no
> OBLIGATION to do optimization work based on information of inputs from
> zero_one_hot() code even though they are designed to do so for the
> purpose.
>
> What an assertion function can do is to return its value: true or
> false, how can it be used to transfer mutually exclusive information
> to VHDL compiler? IT IS ILLEGAL !
>
> If so, that is totally different from 'orif' meaning: for 'orif' It
> not only gives the mutually exclusive information, but also orders:
> 1. VHDL compiler to do code optimization based on the mutually
> exclusive information;
> 2. Simulator to check if related mutually exclusiveness is met.
>
> Because it is a keyword, it has AUTHORITY to issue two different
> commands to VHDL compiler and simulator, respectively, and the orders
> are mandated and it has no code to execute.
>
> Finally I got my point.
>
> Weng

Weng,

Your logic is completely, fatally flawed.

For example, an integer declaration like:

signal myint: integer range 0 to 255;

Only tells the simulator that it cannot put a value outside the range
of 0 to 255, inclusive, into myint. There is no authority to command
that a synthesis tool implements myint as an 8 bit value, but every
single synthesis tool in existence will do just that.

Taken a step further, a counter, coded with an integer, will not roll
over automatically. Yet the synthesis tool understands that the
definition of the integer type means that when the maximum value is
incremented (and stored back to the integer!), the result is undefined
(i.e. would cause an assertion in the simulator). With this
information, the synthesis tool creates the circuit such that it would
roll over if that ever happened, since it is free to do so because
there is no simulator behavior to match in that case. The reason the
synthesis tool creates such a hardware counter is that it takes less
hardware to roll over than to do anything else. Again, the language
did not command the synthesis tool to do it, but the language gave the
synthesis tool enough information that it could make the optimization.

I have seen cases where I defined a counter with a range of 0 to 5.
The synthesis tool optimized the decode function for the value 5
because it knew that 7 was not allowed (this may have also been the
result of a reachability analysis on the code for the counter). There
was no command to do that, it just did it, because it could do so,
while preserving the behavior of the code.

Likewise, an assertion does not "command" a synthesis tool anything.
But, just like ranges on integers, the assertion gives the synthesis
tool information that it can use to optimize the circuit
appropriately.

Declaring an array of vectors, and accessing only one or two elements
(single or dual port) per clock cycle, does not "command" the
synthesis tool to do anything. Yet most, if the target allows it, will
implement the circuit with a RAM, because the synthesis tool
recognizes that a RAM is the most efficient way to implement the
behavior.

Your concept of the VHDL language "commanding" the synthesis tool to
do things is not accurate. The synthesis tool simply, to the best of
its ability, creates a circuit that exhibits the same behavior that
the code would exhibit in a simulator. There are standardized methods
of describing the behavior (e.g. clock edge specifications, etc.) so
that all tools will recognize the same behavior and implement it in a
similar manner, but the language is not commanding the synthesis tool
to do anything except implement the behavior in a circuit.

Andy


Article: 123635
Subject: Re: Is it possible to make bit files generated by Xilinx ISE readable?
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 31 Aug 2007 11:06:40 -0400
Links: << >>  << T >>  << A >>
"Wei Wang" <camwwang@gmail.com> wrote in message 
news:1188567511.682790.293520@19g2000hsx.googlegroups.com...
>I thought the bit files generated by Xilinx ISE should be in plain
> binary format, but actually the .bit file is unreadable when opened in
> XEmacs,

Which exactly means that it is a plain binary file :)

/Mikhail 



Article: 123636
Subject: Re: Spartan 3E - Readback via JTAG
From: "Benni V." <benniv.sep08@googlemail.com>
Date: Fri, 31 Aug 2007 15:41:10 -0000
Links: << >>  << T >>  << A >>
Hi,

On 31 Aug., 14:00, Uwe Bonnes <b...@hertz.ikp.physik.tu-darmstadt.de>
wrote:
> > [4] XAPP452 http://www.xilinx.com/bvdocs/appnotes/xapp452.pdf
> Hope this helps

thanks for your help.

Actually I think I found the commands in the *.rbb-file, which,
according to XAPP452, starts with the binary command sets.

So, for reference, here the commands which hopefully work :-)

0xffff ffff // Sync
0xaa99 5566 // Sync
0x3001 c001 // IDCODE Register
0x01c2 2093 // XC3S500E
0x3000 2001 // FAR Write Packet Header
0x0000 0000 // FAR Write Packet Data (0h)
0x3000 8001 // CMD Write Packet Header
0x0000 000b // CMD Write Packet Data (SHUTDOWN)
0x3000 8001 // CMD Write Packet Header
0x0000 0007 // CMD Write Packet Date (RCRC)
0x2000 0000 // NOP
0x2000 0000 // NOP
0x2000 0000 // NOP
0x2000 0000 // NOP
0x3000 8001 // CMD Write Packet Header
0x0000 0004 // CMD Write Packet Data (RCFG)
0x2800 6000 // FDRO Read Packet Header (Type 1)
0x4801 149a // FDRO Read Packet Header (Type 2), Word-Counter 1149Ah
... ... ...
0x3000 8001 // CMD Write Packet Header
0x0000 0005 // CMD Write Packet Data (START)
0x3000 8001 // CMD Write Packet Header
0x0000 0007 // CMD Write Packet Data (RCRC)
0x3000 8001 // CMD Write Packet Header
0x0000 000d // CMD Write Packet Data (DESYNCH)
0x2000 0000 // NOP
0x2000 0000 // NOP
0x2000 0000 // NOP
0x2000 0000 // NOP

Greetings
Benni


Article: 123637
Subject: Re: PCB Impedance Control
From: "John_H" <newsgroup@johnhandwork.com>
Date: Fri, 31 Aug 2007 08:51:42 -0700
Links: << >>  << T >>  << A >>
"Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message 
news:st8gd39018b9sr1aqur727crpgdqjc2nbf@4ax.com...
> Hi -
>
> On Fri, 31 Aug 2007 13:38:11 +0100, Brian Drummond
> <brian_drummond@btconnect.com> wrote:
>
>>On Fri, 31 Aug 2007 11:02:13 +0100, "Symon" <symon_brewer@hotmail.com>
>>wrote:
>>
>>>"John_H" <newsgroup@johnhandwork.com> wrote in message
>>>news:13de6b5q88e3ke1@corp.supernews.com...
>>>> "PeteS" <axkz70@dsl.pipex.com> wrote in message
>>>> news:H-ydnSZMEttzlkrbnZ2dnUVZ8vidnZ2d@pipex.net...
>>>> <snip>
>>>>>
>>>>> I have a number of pretty pics I made to illustrate the issue. I'll 
>>>>> put
>>>>> 'em on a.b.s.e tomorrow sometime.
>>>>>
>>>>> As an aside, at high speeds (which I define as having a track longer 
>>>>> than
>>>>> 1/4 rising/falling edge, YMMVG), there is no such thing as 'ground'. 
>>>>> The
>>>>> ground plane is a signal layer insulated by copper ;)
>>>>> [Although it helps to keep large power currents away from the high 
>>>>> speed
>>>>> return paths].
>>>>>
>>>>> Cheers
>>>>>
>>>>> PeteS
>>>>
>>>> Since without a ground one has a dipole antenna, could you qualify what
>>>> you mean?  The impedance of the plane is measured in units of picoHenry
>>>> per square so it's not a solid ground, certainly, but without a ground
>>>> we'd be in a world of hurt at these high frequencies.
>>>>
>>>I think Pete means that at high frequencies the skin effect means that 
>>>the
>>>current in the plane is all on one surface of the plane. Thus the bulk of
>>>the plane might as well be an insulator. Or something like that?
>>
>>I think he means the return current is mostly localised directly under
>>the signal track; the copper under the "space" between tracks carries
>>relatively little current and could *almost* be replaced by insulator.
>>
>>- Brian
>
> Seems to me you're both right: the return current is bunched up under
> trace, on the side of the ground plane adjacent to the trace.  This
> "path" is surrounded by copper.  To paraphrase Doug Smith, a local EMC
> consultant, the other side of the plane might as well be on the moon.
>
> Bob Perlman
> Cambrian Design Works
> http://www.cambriandesign.com

Thanks to everyone for devining what PeteS means.
I understand skin effect.
I understand the confinement of return current for high frequencies.
I don't understand the statement that "there is no such thing as 'ground'."

I was hoping Pete could conjecture what Pete meant.

- John_H 



Article: 123638
Subject: Re: Memory bandwidth of the 3A kit
From: Simon <google@gornall.net>
Date: Fri, 31 Aug 2007 15:58:09 -0000
Links: << >>  << T >>  << A >>
On Aug 31, 7:39 am, Simon <goo...@gornall.net> wrote:
> Antti, did you ever get a feel for what memory bandwidth you actually
> get with this setup ? For example, if you had a blockram being
> constantly filled from DDR2 ram, how many MB/sec you can actually pull
> over the bus ?
>
> Wondering whether to buy (yet another) starterkit ... [grin]
>
> Cheers,
>    S.

Ah, dammit. I thought I was replying to http://tinyurl.com/3dcopy, not
starting a new post...



Article: 123639
Subject: Re: New keyword 'orif' and its implications
From: Jim Lewis <jim@synthworks.com>
Date: Fri, 31 Aug 2007 09:12:40 -0700
Links: << >>  << T >>  << A >>
Weng,
Synthesis tools already commonly handle some form of
attributes and metacomments.

Attributes (I have used flavors of the following in both
Xilinx and synplicity):
   signal T1, T2 : std_logic;
   Attribute keep : boolean ;
   Attribute keep of T1, T2 : signal is true ;

Metacomments:
   -- pragma synthesis_off
   -- pragma synthesis_on


Assertions are nothing more than a simple extension.
I thought I heard that Synplicity is already
synthesizing some assertions of their own.

Jim

Article: 123640
Subject: Re: Is it possible to make bit files generated by Xilinx ISE readable?
From: Jim Wu <jimwu88NOOOSPAM@yahoo.com>
Date: Fri, 31 Aug 2007 09:39:22 -0700
Links: << >>  << T >>  << A >>
On Aug 31, 10:07 am, John_H <newsgr...@johnhandwork.com> wrote:
> Wei Wang wrote:
> > I thought the bit files generated by Xilinx ISE should be in plain
> > binary format, but actually the .bit file is unreadable when opened in
> > XEmacs, just wondering whether it is possible to make these bit files
> > readable? Many thanks, -Wei
>
> You can generate .rbt files that are ASCII ones and zeros, .mcs files
> that are formatted for programmers... take a look at the options in bitgen.

Also you can run hexl-mode in Emacs to display binary file in hex
mode. Or you can use just any hex-viewer/editor for this purpose.

Cheers,
Jim
http://home.comcast.net/~jimwu88/tools/


Article: 123641
Subject: Re: New keyword 'orif' and its implications
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Fri, 31 Aug 2007 09:54:33 -0700
Links: << >>  << T >>  << A >>
On Aug 31, 9:12 am, Jim Lewis <j...@synthworks.com> wrote:
> Weng,
> Synthesis tools already commonly handle some form of
> attributes and metacomments.
>
> Attributes (I have used flavors of the following in both
> Xilinx and synplicity):
>    signal T1, T2 : std_logic;
>    Attribute keep : boolean ;
>    Attribute keep of T1, T2 : signal is true ;
>
> Metacomments:
>    -- pragma synthesis_off
>    -- pragma synthesis_on
>
> Assertions are nothing more than a simple extension.
> I thought I heard that Synplicity is already
> synthesizing some assertions of their own.
>
> Jim

Hi Jim,
If you use Attributes to declare mutually exclusiveness, I think it is
OK, no problem. Because attributes is only used for compilers. But
your method is using a function whose input contents are expected to
be transferred to compiler, it is unprecedented !!!

Using an attributes is certainly more natural than Jim's assertion
function().

Adam,
I don't dispute your claim that if mutually exclusive group is
declared, they have their advantages over 'orif'. In my paper in 2002,
I declared two methods, one for 'orif', another for keyword
'Exclusive' to declare not only a group of signals, but a group of
state machines. At that time, I knew both had their own advantages in
different situations.

Now the problems are:
1. Jim's method uses assertion function(); Why don't we use attribute?
No precedent example can be found by using a assertion function()
structure to transfer information to VHDL compiler.

2. Including a group mutually exclusive method shouldn't expel another
on-line programming method 'orif'. That is my point !!! Get two
methods and let engineers to determine what best fit their demand.

3. There are a lot of situations that your variable counter method
fails, but 'orif' method best fits.

I will re-post my longest 'orif' code segment from my coding to show
you the other alternative way to do the same things.

Please count how many conditions contained in if() and elsif() whose
equations in any of your project you use loop structure to generate,
and tell me the ratio.

My ratio is 95/5 in favor of on-line programming.

In my opinion, your mutually exclusive situations should be expected
to have the same ratio.

4. Your coding has a big and fatal problem and never should be used in
any situations like that:
assert zero_one_hot(((TWindowLoad_E0_L_H and nC_BE_R0(3) = '0'),
    (TWindowLoad_E0_H_H and nC_BE_R0(7) = '0')));

Why? I will tell you later. Think of it yourselves and you should know
why.

Weng





Article: 123642
Subject: Simple Project involving microblaze
From: Amir <amiri.amir@gmail.com>
Date: Fri, 31 Aug 2007 10:33:27 -0700
Links: << >>  << T >>  << A >>
Hello Everyone!

Can anyone suggest a simple exemplary FPGA project involving
microblaze using ISE tools rather than EDK? I am pretty at ease with
desiging custom IP modules targetting Xilinx FPGAs, but never tried an
embedded project with a microcontroller.

Any suggestions is very much appreciated...

Regards,

Amir,


Article: 123643
Subject: Re: SDF File basics
From: "asic1234@gmail.com" <asic1234@gmail.com>
Date: Fri, 31 Aug 2007 17:44:25 -0000
Links: << >>  << T >>  << A >>
On Aug 31, 2:09 am, Jon Beniston <j...@beniston.com> wrote:
> On 29 Aug, 22:49, "asic1...@gmail.com" <asic1...@gmail.com> wrote:
>
> > What does SDF, and Back-annotation/Forward annotation mean? How is an
> > SDF File generated and by which tool?
>
> > Can someone explain how to do synthesis and what tools/file
> > extensions
> > (.sdf, .lib etc)  mean?
>
> The Standard Delay Format (SDF) file stores the timing data generated
> by. EDA tools for use at any stage in the design process.www.eda-stds.org/sdf/sdf_3.0.pdf
>
> SDF can be generated by most ASIC synthesis, P&R or STA tools.
> Accuracy will vary though depending upon which stage in the design
> process you are).
>
> As to how to perform synthesis, read the user guide for your synthesis
> tool.
>
> Cheers,
> Jon

Thank you Jon.

So my understanding is that

RTL Code + synopys Design Constraint (.sdc) files are fed into
synthesis tool, it generates a .v / .vg netlist file plus the .sdf
file. Correct?


Article: 123644
Subject: signal termination in spartan 3e starter kit
From: "asimatta@hotmail.com" <asimatta@hotmail.com>
Date: Fri, 31 Aug 2007 10:44:36 -0700
Links: << >>  << T >>  << A >>
hi
i am new to FPGA designs. i have a question about signal termination.
the spartan 3e starter kit has a 10 ohm resistance in series and 10 pf
capacitor to ground between CCLK pin of FPGA and CLK pin of
Configuration PROM. i think this is for reducing signal reflection. Is
it a good choice for doing this or do we need a parallel termination.
and if we need a parallel termination then where it should be
placed..on PROM end or FPGA end ? (master serial configuration)
do we need termination for TCK signal if there is only a PROM and a
FPGA in the chain ?


Article: 123645
Subject: Xilinx ML40x Mouse VHDL Wanted
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Fri, 31 Aug 2007 11:42:02 -0700
Links: << >>  << T >>  << A >>
Does anybody have VHDL code to
run the mouse port on an ML40x dev board?

Brad Smallridge
Ai Vision



Article: 123646
Subject: what does asynchronous loop mean?
From: "asic1234@gmail.com" <asic1234@gmail.com>
Date: Fri, 31 Aug 2007 18:51:17 -0000
Links: << >>  << T >>  << A >>
Is it bad to have async loop? If so, why?


Article: 123647
Subject: Re: Simple Project involving microblaze
From: young <zhang.young@gmail.com>
Date: Fri, 31 Aug 2007 18:52:59 -0000
Links: << >>  << T >>  << A >>
Currently, Xilinx recomend to instantize the system.xmp as a source
file in ISE 8 or 9.
You can treat the whole EDK project as a component after you add the
system.xmp file into you ProjNavigator.

On Aug 31, 1:33 pm, Amir <amiri.a...@gmail.com> wrote:
> Hello Everyone!
>
> Can anyone suggest a simple exemplary FPGA project involving
> microblaze using ISE tools rather than EDK? I am pretty at ease with
> desiging custom IP modules targetting Xilinx FPGAs, but never tried an
> embedded project with a microcontroller.
>
> Any suggestions is very much appreciated...
>
> Regards,
>
> Amir,



Article: 123648
Subject: BlockRAM connection error
From: young <zhang.young@gmail.com>
Date: Fri, 31 Aug 2007 19:16:11 -0000
Links: << >>  << T >>  << A >>
Hi all,

I met a wired BlockRam connection error when I tried to build a
mutilple processors system using EDK. Hope anyone can give me some
hint.

Here is the background.   With the EDK, we can create a single
processor (MicroBlaze or PowerPC) at ease. Based on
the single Processor sytem, I added those IPs,  including the
processor (MB or PPC), the bus , BRAM memory, memory
controller and some pherpherals. I connected them in the same way the
single processor system do, which needs some modification in the mhs
file.
There is no connections between two processor system. In the Build
process, the project passed the syntheis and failed in the map. The
message is this:
---------------------------------------------------------------------------------------------------------------------------------

#----------------------------------------------#
# Starting program map
# map -o system_map.ncd -pr b system.ngd system.pcf
#----------------------------------------------#
Release 9.1.02i - Map J.33
Copyright (c) 1995-2007 Xilinx, Inc.  All rights reserved.
Using target part "2vp30ff896-7".
Mapping design into LUTs...Mapping design into LUTs...
ERROR:MapLib:482 - Blockram ramb16_s9_s9_0 is a memory mapped blockram
generated
   for the Microprocessor. However it is not connected properly,
causing it to
   be trimmed. Please connect up all memory mapped blockram properly
and re-run
   Ngdbuild.
ERROR:MapLib:482 - Blockram ramb16_s9_s9_1 is a memory mapped blockram
generated
   for the Microprocessor. However it is not connected properly,
causing it to
   be trimmed. Please connect up all memory mapped blockram properly
and re-run
   Ngdbuild.
ERROR:MapLib:482 - Blockram ramb16_s9_s9_2 is a memory mapped blockram
generated
   for the Microprocessor. However it is not connected properly,
causing it to
   be trimmed. Please connect up all memory mapped blockram properly
and re-run
   Ngdbuild.
ERROR:MapLib:482 - Blockram ramb16_s9_s9_3 is a memory mapped blockram
generated
   for the Microprocessor. However it is not connected properly,
causing it to
   be trimmed. Please connect up all memory mapped blockram properly
and re-run
   Ngdbuild.
ERROR:MapLib:482 - Blockram ramb16_s9_s9_4 is a memory mapped blockram
generated
   for the Microprocessor. However it is not connected properly,
causing it to
   be trimmed. Please connect up all memory mapped blockram properly
and re-run
   Ngdbuild.
ERROR:MapLib:482 - Blockram ramb16_s9_s9_5 is a memory mapped blockram
generated
   for the Microprocessor. However it is not connected properly,
causing it to
   be trimmed. Please connect up all memory mapped blockram properly
and re-run
   Ngdbuild.
ERROR:MapLib:482 - Blockram ramb16_s9_s9_6 is a memory mapped blockram
generated
   for the Microprocessor. However it is not connected properly,
causing it to
   be trimmed. Please connect up all memory mapped blockram properly
and re-run
   Ngdbuild.
ERROR:MapLib:482 - Blockram ramb16_s9_s9_7 is a memory mapped blockram
generated
   for the Microprocessor. However it is not connected properly,
causing it to
   be trimmed. Please connect up all memory mapped blockram properly
and re-run
   Ngdbuild.
Error found in mapping process, exiting...
Errors found during the mapping phase.  Please see map report file for
more
details.  Output files will not be written.
---------------------------------------------------------------------------------------------------------------------------------

If anyone share the same error, I would appreciate your comment.

Regards,

Young


Article: 123649
Subject: Re: what does asynchronous loop mean?
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Fri, 31 Aug 2007 14:29:32 -0500
Links: << >>  << T >>  << A >>

>Is it bad to have async loop? If so, why?

The timing analyzer probably won't do what you want.


What are you trying to build?  A ring oscillator?  A latch?

Unless you know what you are doing, it's probably a bug in
your logic.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.




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