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 61675

Article: 61675
Subject: Re: Visualizing VHDL
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Wed, 08 Oct 2003 20:46:52 GMT
Links: << >>  << T >>  << A >>
"Jon Elson" wrote:

> I needed to delay some signals, and just threw in some extra gates.
> Of course, this had no effect on the boolean functions from input
> to output, and so were optimized away.  So, finally, I realized I
> needed to bring signals off-chip, through an external RC, and back
> in to do what I wanted.

Ouch!  This is really, I'll repeat, really bad design practice.  Even if it
worked (and there are way to make it work) you'd be primed and ready to be
victimized by a whole host of variables that can break your delay or make it
problematic at best.

You can't just draw pretty schematics without having a sense of what's in
the chip and how your schematic will be translated.  That's suicide.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 61676
Subject: Re: Problem with PCI cards
From: "Nial Stewart" <nial@spamno.nialstewart.co.uk>
Date: Wed, 8 Oct 2003 22:08:34 +0100
Links: << >>  << T >>  << A >>

H. Peter Anvin <hpa@zytor.com> wrote in message
news:bm1siq$847$1@cesium.transmeta.com...
> Followup to:  <3f84344a$0$10982$fa0fcedb@lovejoy.zen.co.uk>
> By author:    "Nial Stewart" <nial@spamno.nialstewart.co.uk>
> In newsgroup: comp.arch.fpga
> >
> > _Are_ these completely stupid if the host has performed the
> > memory mapping configuration?
> >
> > BAR0 is IO space mapped to 0xBC00
> >
> > BAR1 is memory space which is pre-fetchable from
> > 0xF4400000 to 0xF4800000
> >
>
> It's actually impossible to know without knowing what the powerup
> values are and which bits are read/write.  Just posting a snapshot in
> time is pretty useless -- you need to go and check the proper
> semantics of all your bits.
>   -hpa

Aye, but they could be valid values after config OK, couldn't they?

I don't think Andy was correct in saying the BAR0 and BAR1 values
are completely stupid without more info.

?

Nial

------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk




Article: 61677
Subject: Re: syncing the CLK0 outputs of two DCMs if they use CLKIN_DIVIDE_BY_2
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 08 Oct 2003 14:25:14 -0700
Links: << >>  << T >>  << A >>
John,

There is no way to synchronize two separate DCM CLKDV outputs in phase,
nor is there a way to synchronize the CLKDV with the CLKFX phase (where
they are both say dividing by 1/2) that we are aware of.

This is a deficiency that we realized, and are planning to fix in
subsequent generations.

The logic that generates the sequence has no ability to be reset or
strobed by a user logic signal to cause them to be in sync.

Just to help us, why do you do the same thing twice?  If you explain
what you are doing, perhaps there is another way to do it?

Austin


John Providenza wrote:

> If I have a 500MHz input clock feeding into two DCMs in a Virtex-II
> with the CLKIN_DIVIDE_BY_2 option set on both of them....
>
> The CLK0 output of each of them should be 250MHz, but it seems
> like they could come up 180 degrees out of phase.
>
> Is there any way to have the CLK0 outputs of the two DCMs
> come up "in phase" without playing tricks with the CLKFB
> signals between the two of them?
>
> Thanks
>
> John Providenza


Article: 61678
Subject: Re: Problem with PCI cards
From: H. Peter Anvin <hpa@zytor.com>
Date: 8 Oct 2003 14:44:33 -0700
Links: << >>  << T >>  << A >>
Followup to:  <3f847c16$0$10988$fa0fcedb@lovejoy.zen.co.uk>
By author:    "Nial Stewart" <nial@spamno.nialstewart.co.uk>
In newsgroup: comp.arch.fpga
> 
> Aye, but they could be valid values after config OK, couldn't they?
> 
> I don't think Andy was correct in saying the BAR0 and BAR1 values
> are completely stupid without more info.
> 

The BAR0/1 values look plausible, yes.

	-hpa
 


-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Article: 61679
Subject: Re: MICROBLAZE: Using external instruction memory
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Thu, 09 Oct 2003 07:56:36 +1000
Links: << >>  << T >>  << A >>
Hi Arkaitz,

arkaitz wrote:
> I've done a flash loader but I don't know which file do I have to
> store in flash in order to enable to execute it.
> 
> I've proved storing the "executable.elf" file which contains the
> crt0.o initialization code linked and then I jump to that address from
> a program stored in the Block RAMS, but as I supposed it doesn't work.

you must use mb-objdump utility to convert the elf file into an 
executable binary image.  elf files themselves cannot be directly 
executed, they must be loaded, have the relocations resolved, etc etc. 
You want something like:

mb-objcopy -O binary --remove-section=.stab --remove-section=.stabstr 
executable.elf executable.bin

The --remove-section options are specifying not to copy debug string 
information into the final binary.

Then, once you have your executable.bin file - that is the code you want 
to place into flash, prior to being copied into RAM for execution.

This is how kernel images for microblaze uClinux (and most other uClinux 
ports) are done.

Regards,

John


Article: 61680
Subject: Re: MICROBLAZE: Using external instruction memory
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Thu, 09 Oct 2003 07:57:12 +1000
Links: << >>  << T >>  << A >>
John Williams wrote:
> Hi Arkaitz,
> 
> arkaitz wrote:
> 
>> I've done a flash loader but I don't know which file do I have to
>> store in flash in order to enable to execute it.
>>
>> I've proved storing the "executable.elf" file which contains the
>> crt0.o initialization code linked and then I jump to that address from
>> a program stored in the Block RAMS, but as I supposed it doesn't work.
> 
> 
> you must use mb-objdump utility to convert the elf file into an 
                 ^^^^^^^^^

oops I meant objcopy of course!


Article: 61681
Subject: Placing FF's Relative to RAMB4s (xilinx)
From: "Morten Leikvoll" <m-leik@online.nospam>
Date: Thu, 9 Oct 2003 01:03:03 +0200
Links: << >>  << T >>  << A >>
My design places the FF in front of a RAMB4 on a VirtexE strangely. I have a
macro and I place all the RAMB4's (6 in total, 2 in each macro) on one
column by using for example LOC=RAMB4_R0C2:RAMB4_R7C2.
Now I can not find an easy one to place close to their RAMs without
specifying for each macro separately. I want to place the FF's in front of
the data and address inputs as close as possible (delay wise) to these
RAMB4's. Is there an easy way to do this?




Article: 61682
Subject: Re: Digesting runs of ones or zeros "well"
From: Ray Andraka <ray@andraka.com>
Date: Wed, 08 Oct 2003 19:33:36 -0400
Links: << >>  << T >>  << A >>
I'd rather use a function or procedure within the HDL so that the boolean expression
is in the code and is used directly to generate the init value.  Otherwise, there is
a high chance of either transcription error or not updating the comment with the
boolean
expression.  There is a link on my website to one such VHDL function.

"H. Peter Anvin" wrote:

> Followup to:  <3F83932E.16B23BC6@andraka.com>
> By author:    Ray Andraka <ray@andraka.com>
> In newsgroup: comp.arch.fpga
> >
> > The first method gives you structure but no handles for naming or placing the
> > LUTs.  The second is one I use for many of my library macros, as it permits
> > attachment of an RLOC placement attribute so you can get control over placement.
> > It does however result in a large library of small combinatorial functions which
> > can become awkward to maintain.  The third is generally too hard to use and
> > maintain without a good INIT string generation function, however it does not
> > require a large library of 2,3 and 4 input functions.  It is hardly usable
> > without the boolean to INIT function however.
> >
>
> Here is a simple Perl script that produces the appropriate LUT bit
> pattern for a 4-input LUT given any arbitrary boolean expression
> involving "0", "1", "a", "b", "c", "d".  The operators are the stanard
> C/Perl ~ | ^ & -- the booleanizing operators including ?: and ! should
> not be used.  The extension to 5-input LUTs should be obvious.
>
> This should be easily tweakable to produce any particular syntax
> desired.
>
> Posted mostly as an example.
>
>         -hpa
>
> #!/usr/bin/perl
>
> $e = join(' ', @ARGV);
> $e =~ s/1/\(\$one\)/g;
> $e =~ s/a/\(\$a\)/g;
> $e =~ s/b/\(\$b\)/g;
> $e =~ s/c/\(\$c\)/g;
> $e =~ s/d/\(\$d\)/g;
>
> $one = 0xffff;
> $a   = 0xaaaa;
> $b   = 0xcccc;
> $c   = 0xf0f0;
> $d   = 0xff00;
>
> printf "%04x\n", eval($e) & $one;
>
> --
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
> If you send me mail in HTML format I will assume it's spam.
> "Unix gives you enough rope to shoot yourself in the foot."
> Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 61683
Subject: Re: Should I worry about metastability
From: Ray Andraka <ray@andraka.com>
Date: Wed, 08 Oct 2003 19:37:23 -0400
Links: << >>  << T >>  << A >>
I think the correct term is higher jitter.  As I recall, the Philips video
decoders have
something like 8 uS max jitter, which is nearly 100x the permissible jitter on
Spartan2 and Virtex.  Also, that jitter spec is for an established video
signal.  If
you disconnect and reconnect the video signal, the PLL output goes out to lunch
for
a period of time, which is something the DLLs decidedly don't like.

Simon Peacock wrote:

> Have a talk to your friendly Xilinx Apps engineer  Spartan 3's can tolerate
> a high jitter (So I've read) .. they just wont tell you that except under
> NDA.
>
> Simon
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3F8325DD.371B7949@andraka.com...
> > Nope,  Jitter out of the video decoders is about 10x what is allowed by
> the
> > DLL/DCM.  I posted earlier a solution that works fine for this, and is
> used in
> > a number of my customer's products.
> >
> >
> >
> > Simon Peacock wrote:
> >
> > > If you pick the right xilinx you could multiply the 27MHz up to 108MHz
> > > internally.  Just use the internal PLL
> > >
> > > Simon
> > >
> > > "Guy Eschemann" <geschemann@yahoo.fr> wrote in message
> > > news:b9f16a5b.0310062304.4b75202a@posting.google.com...
> > > > > But you said that the clock was not truly asynchronous, but was 4
> times
> > > > > the data rate, with an unknown ( but stable?) phase relationship.
> > > > >
> > > >
> > > > Maybe my description was a bit confusing, sorry for this. The clocks
> > > > really are asychronous. There is no stable phase relationship between
> > > > them, since the 27MHz clock is the ouput of a PLL locked on the H-Sync
> > > > of a video signal, and the 108MHz system clock is derived from a 27MHz
> > > > crystal oscillator.
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> >  "They that give up essential liberty to obtain a little
> >   temporary safety deserve neither liberty nor safety."
> >                                           -Benjamin Franklin, 1759
> >
> >

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 61684
Subject: Re: More RPM / RLOC fun
From: Ray Andraka <ray@andraka.com>
Date: Wed, 08 Oct 2003 19:52:51 -0400
Links: << >>  << T >>  << A >>
Goran,

I can't understand why you are working in flatland.  First off, it creates a bunch of

extra typing.  If you use H_SETs, there is no need to explicitly declare each set, it

is done automatically  for you, and then you can piece together the RLOCs without
having to pass placement information into your lower levels.  Using USETs means
you need a unique name for each instance of a macro, plus you need to compute the
offsets for each and manually (in your code) add them to the RLOCs before applying
the RLOCs.  With HSETs, that is all done automatically, so each module is truely
standalone.  That means with HSETs you can compile parts of the code and then
instance it as a black box in a higher level.  I'm not sure of the motivation for
handling
all the floorplanning in one place either.  Seems to me that the floorplanning should

be with the module, as your layout normally will be the same regardless of where
you put it. (I do have some with alternative layouts such as swapped horizontal, in
which case I use generics to control the layout.  A simple case is whether the origin

is at the top or the bottom of a carry chain, which is illustrated partly below).

I handle the different RLOC strings for RC or XY grids by creating both strings and
then using a pickstring function to select which gets used. Pickstring has an
argument for the family
(0=unplaced, 1= virtex/spartanII, 2=v2, 3=spartan3) plus an RC sting and an XY
string.  In the
case of unplaced, it returns the null string.  For 1 it returns the RC string, and
for 2 or more the xy string
For example:
 constant rc_str : string := "R" & itoa( origin -(i/2))  & "C0" & ".S" & itoa(slice
mod 2);
 constant xy_str : string := "x0y" & itoa((i/2)-origin) ;
 constant rloc_str : string := pickstring(virtex,rc_str,xy_str);
 signal l,d,qr,qs: STD_LOGIC;
 attribute BEL of U1:label is bel_lut(i mod 2);
 attribute RLOC   of U1 : label is rloc_str;


Is there some advantage of doing this flat that has totally escaped me?


--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 61685
Subject: Re: synplify vqm not able to fit in Quartus
From: Andrew Dauman <andrew@synplicity.com>
Date: Thu, 09 Oct 2003 00:14:31 GMT
Links: << >>  << T >>  << A >>
I believe the answer may be that you have too much logic for the device.

When Synplify packs to Atoms, we expect very good area correlation. 
That’s because we packed all the Atoms into legal configurations.
When Synplify does not pack to Atoms, we measure resource usage of 
individual elements of the Atoms, but we do not estimate Atom usage 
accurately. Sometime 2 elements that could fit into an empty Atom can 
not be packed together because it would not be a legal configuration. 
So, even though I might have a resource report that shows  usage of 1 
LUT and 1 Register, it could require 2 Atoms instead, instead of 1. 
Since Synplify did not do the packing, Quartus will determine the legal 
packing.  In your example, when we packed it it did not fit, and when 
Quartus packed it it did not fit. That makes me think that things are 
consistent. As the log file says, when Synplify does not do the packing, 
our area report is just an estimate. Again, that is because it reports 
individual element usage and does not assess legal packing configurations.


This is only a guess, to be sure we would need to take a look at your 
example. Please feel free to send the test case to “support” at 
synplicity.com and we will have someone try to help fit it into your 
device, and also to clarify the reason for the difference.

Andrew Dauman
Synplicity, Inc.


Bob wrote:
> Hi,
> 
> I am trying to fit this particular design. I run Synplify Pro to map
> the device.
> In Synplify, with mapping logic to atoms turned on, the design won't
> fit so I disable mapping logic to atoms and can get the design to fit
> (63 % of device)
> onto the device....see log file from synplify below. 
> 
> However, when I try to place and route the device in Quartus III, it
> cannot fit.
> Quartus uses the same project directory as Synplify so it has access
> to all constraints and tcl files. Can anybody shed any light on this
> subject. I have used Synplify in conjunction with Quartus before and
> the resource useage results
> from both are nearly always about the same. Why the large discrepency
> ?
> 
> Do I manually need to read in some tcl files or have I forgotten to
> switch on
> a particular option in Quartus ?
> 
> As always, thanks for any help
> Bob
> 
> 
> 
> 
> 
> 
> Found clock clk with period 33.3333ns
> ---------------------------------------
> Resource Usage Report
> 
> Final cell packing will be performed by Max+plus II.
> Please select a Logic synthesis style of "FAST" in Max+plus II.
> The following resource values are estimates.
> 
> Design view:work.comms(comms_architecture)
> Selecting part ep20k1000efc33-1
> 
> Logic resources:  24440 ATOMs of 38400 (63%)
> Number of Nets:   190215
> Number of Inputs: 1298480
> Register bits:    14312 (4094 using enable)
> Latch bits:      8106
> ESBs:                0  (0% of 160)
> I/O cells:       0
> 
> Details:
> AND2:           8298
> INV1:           3879
> MUX1:           5834
> SYNLPM_LAT1:    16356
> S_DFF:          10218
> S_DFFE:         4113
> XOR2:           291
> apex20k_lcell:  77185
> apex20k_lcell_ff: 19
> false:          7
> inv:            9189
> true:           7
> 
> Number of Inputs on ATOMs: 1298480
> Number of Nets:   190215
> 
> Writing .vqm output for Quartus
> Writing Cross reference file for Quartus to
> c:\comms_vhdl\rev_1\comms.xrf
> Mapper successful!
> Process took 7284.92 seconds realtime, 7284.92 seconds cputime


Article: 61686
Subject: Re: Visualizing VHDL
From: "Patrick MacGregor" <patrickmacgregor@comcast.net>
Date: Wed, 8 Oct 2003 20:54:14 -0400
Links: << >>  << T >>  << A >>
I visualize what I want, then draw a schematic of it.  Then I think to
myself "...self, the design is now done, why bother with that HDL garbage at
all?..."

I've never been able to come up with a compelling reason to go beyond
schematics, once the job is done.  That would be like working for the
Department of Redundancy Department.

An added bonus is that I'm off doing the next job instead of numbing my
brain by turning a perfectly good schematic design into a perfectly useless
text file.




"Kevin Kilzer" <kkilzer.remove.this@mindspring.com> wrote in message
news:qg97ovc5hrf4aii8qe858uljdpg14d5rp9@4ax.com...
> When you write VHDL (or Verilog for that matter), do you visualize a
> schematic with wires, gates, flops, latches, muxes, etc., or do you
> use some other way of thinking about it?
>
> Kevin
>



Article: 61687
Subject: Re: Visualizing VHDL
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 09 Oct 2003 01:41:03 GMT
Links: << >>  << T >>  << A >>
"Patrick MacGregor" wrote:

>I visualize what I want, then draw a schematic of it.  Then I think to
>myself "...self, the design is now done, why bother with that HDL garbage
at
>all?..."
...
> I've never been able to come up with a compelling reason to go beyond
> schematics, once the job is done.

Proably because you have yet to run into a design that makes you rethink
your position.  Not a putdown at all, just a fact.  Schematics might be
nicer/easier to deal with (particularly if you are old school) for small,
stable, well-defined projects that might not require a lot of future
maintenance.  In most cases these designs are trivial to implement in HDL.
Please, I say this again, don't take this as a putdown, that's not the
intention here.

Believe me when I say that there's absolutely no doubt that HDL's are the
way to go.  You start getting into large million-gate FPGA's with complex
logic and schematics are not even an option.  Some will use schematics to
wire-together top level entities.  That's fine.  That works.  For anything
else it would be just about insanity to attempt to use schematics.

> turning a perfectly good schematic design into a perfectly useless
> text file.

You start doing non-trivial (from an HDL standpoint) designs and it's the
other way around.  A schematic would be perfectly useless.

I'm not thrilled about still using ASCII to design hardware, don't get me
wrong.  But, until someone come up with a better way to do it, it's the best
we got.  Period.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 61688
Subject: Re: ....and he left with his marbles.....
From: brimdavis@aol.com (Brian Davis)
Date: 8 Oct 2003 19:25:35 -0700
Links: << >>  << T >>  << A >>
Austin,

 "Xilinx is always right" is your personal credo, as evidenced
by this thread and many others.

 The next time you're about to post a sarcastic, condescending,
knee-jerk response to a thread based soley on the fact that it 
is somehow critical of Xilinx's parts, tools, or customer support,
stop to consider whether you can back up your post with an argument
any more compelling than "because I said so".

Brian


Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F842707.AB1AA4DA@xilinx.com>...
> Brian,
> 
> You are absolutely correct in everything you say*.
> 
> Please do not bother to reply or acknowledge, as I am not worthy of your
> attention.
> 
> Austin
> 
> *Note: "customer is always right"

Article: 61689
Subject: Floorplanning, Routing, FPGA Editor
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 09 Oct 2003 02:53:54 GMT
Links: << >>  << T >>  << A >>
In wanting to gain a greater understanding of routing options (particularly
as related to making floorplanning decisions) I find myself studing devices
in the FPGA Editor.  One question that occured to me is: How accurate a
representation of the actual device layout does this tool provide?  Example:

I'm looking at an XC2V100-4FG456.  I see that all embedded multipliers have
the I/O on the left side only.  Obviously all PIP's are on that side as
well.  And there are four switch boxes that would seem to be the best place
to connect in/out of the multipler.  These switch boxes, in turn, would be
the way to access the CLB's to the immediate left and right(through their
own switch boxes).  Double interconnect lines seem to be the best possible
path.

Are these accurate representations of the geometry?  Accurate enough to
decide, for example, that the path from a multiplier, through its switch
box, via a double line, into the CLB to the left is slightly faster than
using the same double line to go to the CLB on the right?

Can any sort of assumptions be made in terms of ps per unit length from what
is seen in FPGA Editor?  What's the cost (delay wise) of going through a PIP
FET?

Is this the wrong approach to making floorplanning decisions?

Thanks,

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 61690
Subject: Re: Floorplanning, Routing, FPGA Editor
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 09 Oct 2003 03:46:32 GMT
Links: << >>  << T >>  << A >>
> I'm looking at an XC2V100-4FG456.

Sorry, XC2V1000


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 61691
Subject: Re: Visualizing VHDL
From: Ray Andraka <ray@andraka.com>
Date: Thu, 09 Oct 2003 00:32:11 -0400
Links: << >>  << T >>  << A >>
A properly done hierarchical schematic can be used in large designs just as
effectively as an HDL.  I'll take a well done schematic over sloppy HDL or  a
well done HDL over sloppy schematics any day.  The key to a readable and
reusable design is extensive use of hierarchy.   The HDLs do have some
advantages:
1) it is far easier to make parameterized macros in an HDL than it is with
schematics.  This is important for design reuse.  It can be done with
schematics, but there is more manual intervention for the reuse.  I know, I've
gotten far more reuse in my business than most businesses achieve both with HDLs
and with schematics.
2) Complex simulations are easier with HDLs, as you can write behavioral models
for the interfacing circuits rather easily without having to create a circuit.
3) Design archives are easier to revisit in that the source is viewable in a
standard text editor.  Schematic editors generally need the same tool they were
created by in order to view electronic archives.  Some schematic editors even
change the format of the databases with new releases.  Viewlogic did that two or
three times over the time that I used it.

The fact of the matter is the industry has moved to HDLs, so in order to keep
yourself marketable (no job is forever), you should bite the bullet and learn at
least one HDL.

>

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 61692
Subject: Re: Floorplanning, Routing, FPGA Editor
From: Ray Andraka <ray@andraka.com>
Date: Thu, 09 Oct 2003 00:34:55 -0400
Links: << >>  << T >>  << A >>
the FPGA editor is about as good as it gets for studying the device.  Yes, it is
faithful to the device for the connections and relative locations of the
blocks.  The router in FPGA editor will return timing for each node on a route
as well.

Martin Euredjian wrote:

> In wanting to gain a greater understanding of routing options (particularly
> as related to making floorplanning decisions) I find myself studing devices
> in the FPGA Editor.  One question that occured to me is: How accurate a
> representation of the actual device layout does this tool provide?  Example:
>
> I'm looking at an XC2V100-4FG456.  I see that all embedded multipliers have
> the I/O on the left side only.  Obviously all PIP's are on that side as
> well.  And there are four switch boxes that would seem to be the best place
> to connect in/out of the multipler.  These switch boxes, in turn, would be
> the way to access the CLB's to the immediate left and right(through their
> own switch boxes).  Double interconnect lines seem to be the best possible
> path.
>
> Are these accurate representations of the geometry?  Accurate enough to
> decide, for example, that the path from a multiplier, through its switch
> box, via a double line, into the CLB to the left is slightly faster than
> using the same double line to go to the CLB on the right?
>
> Can any sort of assumptions be made in terms of ps per unit length from what
> is seen in FPGA Editor?  What's the cost (delay wise) of going through a PIP
> FET?
>
> Is this the wrong approach to making floorplanning decisions?
>
> Thanks,
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_"  =  "martineu"

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 61693
Subject: Spartan 3 pinout typo?
From: jakespambox@yahoo.com (Jake Janovetz)
Date: 8 Oct 2003 21:43:13 -0700
Links: << >>  << T >>  << A >>
Hi folks-

This isn't a significant note, but it seems there is a slight typo in
the PQ208 package pinout for the Spartan 3.  Namely, Bank 1 includes
the following that I believe should be listed as Bank 0:

IO_L32N_0/GCLK7
IO_L32P_0/GCLK6

Although the suffix (_0) indicates they belong in Bank 0, I wanted to
make sure they follow Bank 0 power supplies.  Also, the table at the
end of the listing puts two GCLKs in Bank0 and two in Bank1, so that
seems to reinforce the typo.

Correction?

   Jake

Article: 61694
Subject: Re: Visualizing VHDL
From: Jon Elson <elson@pico-systems.com>
Date: Thu, 09 Oct 2003 00:05:51 -0500
Links: << >>  << T >>  << A >>


Martin Euredjian wrote:
> "Jon Elson" wrote:
> 
> 
>>I needed to delay some signals, and just threw in some extra gates.
>>Of course, this had no effect on the boolean functions from input
>>to output, and so were optimized away.  So, finally, I realized I
>>needed to bring signals off-chip, through an external RC, and back
>>in to do what I wanted.
> 
> 
> Ouch!  This is really, I'll repeat, really bad design practice.  Even if it
> worked (and there are way to make it work) you'd be primed and ready to be
> victimized by a whole host of variables that can break your delay or make it
> problematic at best.
> 
> You can't just draw pretty schematics without having a sense of what's in
> the chip and how your schematic will be translated.  That's suicide.
> 
> 

Well, it is working in a production product.  I didn't need much delay,
and it was not critical at all.  The purpose was to make sure that a
register was incremented at the end of a data transfer, and to be sure
the address lines did not change while the strobe line was still in the
active state.  This is on a CPLD which is the only logic component
on a board.  The board does not have a clock, either.  The delay was
implemented with a 5.1K resistor, and the C is the capacitance of the
input pin of the CPLD.  This is on an XC9572 chip.  The next bus cycle
will be at least 500 nS later.

A related product needs a lot more logic, and it has a clock, so I
used a much more proven delay technique on that one.  It uses a
Spartan FPGA.

Jon


Article: 61695
Subject: Re: synplify vqm not able to fit in Quartus
From: vbetz@altera.com (Vaughn Betz)
Date: 8 Oct 2003 22:38:52 -0700
Links: << >>  << T >>  << A >>
stenasc@yahoo.com (Bob) wrote in message news:<20540d3a.0310060457.37847daf@posting.google.com>...
> Hi,
> 
> I am trying to fit this particular design. I run Synplify Pro to map
> the device.
> In Synplify, with mapping logic to atoms turned on, the design won't
> fit so I disable mapping logic to atoms and can get the design to fit
> (63 % of device)
> onto the device....see log file from synplify below. 
> 
> However, when I try to place and route the device in Quartus III, it
> cannot fit.
> Quartus uses the same project directory as Synplify so it has access
> to all constraints and tcl files. Can anybody shed any light on this
> subject. I have used Synplify in conjunction with Quartus before and
> the resource useage results
> from both are nearly always about the same. Why the large discrepency
> ?
> 
> Do I manually need to read in some tcl files or have I forgotten to
> switch on
> a particular option in Quartus ?
> 
> As always, thanks for any help
> Bob

Bob, 

What is exactly is the no-fit message from Quartus for the two cases
(Synplify maps to atoms, and Synplify doesn't map to atoms)?

I suspect that when Synplify does not map to atoms (an unusual flow
for the 20K -- I've never seen it used before), it doesn't really know
how many logic cells will be used, since it didn't do the mapping.  If
Quartus is simply saying that your design uses too many logic cells in
both of these flows (map to atoms and don't map to atoms), then your
design is just too big.

If it is reasonably close to fitting (i.e. you're using 110% or so of
the logic cells in the device) then there are options you can turn on
in Quartus, like more aggressive register packing, that can compress
the design more.  If Quartus is saying you need double the number of
logic cells in the device, you're probably out of luck.

Vaughn
Altera

Article: 61696
Subject: Re: Visualizing VHDL
From: assaf_sarfati@yahoo.com (Assaf Sarfati)
Date: 8 Oct 2003 22:49:52 -0700
Links: << >>  << T >>  << A >>
Kevin Kilzer <kkilzer.remove.this@mindspring.com> wrote in message news:<qg97ovc5hrf4aii8qe858uljdpg14d5rp9@4ax.com>...
> When you write VHDL (or Verilog for that matter), do you visualize a
> schematic with wires, gates, flops, latches, muxes, etc., or do you
> use some other way of thinking about it?
> 
> Kevin

I never start writing HDL code until I have visualised the design. I don't 
visualise it in my head - I use a graphics program to draw and save the 
stuff (I use Visio).
Browsing old design documentations, I'd say that a visualisation is a mix
of drawing types:

Data path stuff is drawn as a path - busses are arrows, functions are
circles, registers are rectangles.

Control and interface is a combination of state diagrams and annotated
waveform diagrams (clock cycles, cause/event arrows and various comments).

For managing pipelines, I usually draw (or write with a spreadsheet program)
a two-dimentional table, with time as one dimension (clock cycles) and 
the various pipeline stages as the other dimension.

I almost never visualise a design in schematic form - at the most, I see
registers, muxes and a combinatorial logic "cloud".

Hope this helps.

Article: 61697
Subject: Re: beginner - exisit some free schematics programmer for fpga ?
From: Jens Hildebrandt <jens.hildebrandt@remove_this.etechnik.uni-rostock.de>
Date: Thu, 09 Oct 2003 08:00:52 +0200
Links: << >>  << T >>  << A >>
Plenolo wrote:

>>>Hi all i am new in the group, i am a italian student of computer science
> 
> and
> 
>>>i have hobbies for electronics, too... so i have using PIC, St6/7
>>>microcontroller, etc.. now my dream is develop some circuit with fpga
> 
> (or
> 
>>>similar) and VHLD language. I have just a bit studing (only teorically)
> 
> VHDL
> 
>>>in my university, but now i would REALLY program some chip for develop
> 
> some
> 
>>>simple and medium project.
>>>I have not money (and i don't want :-) ) to buy some original developing
>>>system, so i would home build some free "programmer" (in-circuit JTAG
> 
> ???)
> 
>>>how i have do in pass for PIC / St6/7 programmers :-)
>>>
>>
>>You'd be better off on comp.arch.fpga, for the actual hardware
>>questions - I've crossposted to there and set the followups to go
>>there also.
>>
> 
> 
> Ok, now  i am here :-))
> 
> 
>>Regarding programming hardware, Altera have the Byteblaster schematics
>>downloadable from their site, in the Byteblaster datasheet.  I can;t
>>recall if Xilinx have similar.
> 
> 
> Ok thank i have found ByteblasterMV's datasheet
> (http://www.altera.com/literature/ds/dsbytemv.pdf), is it correctly ?
> I have found also a PCB and more at http://c.combaret.free.fr/projects.html
> and i that it can interest at somebody... and i have found a old article
> "Build your own ByteBlaster" from old mirror of "FreeCore Library" at
> http://opencollector.org/history/freecore/What%20Altera%20didn't%20tell%20you.htm
> 
> but i am also interessed to Xilix cpld and fpga so somebody know if exist
> some free programmer like type for Altera chips ?
> 
> Thank you very much ALL
> 
> 
>>>Thank you very much to all friends, and sorry for my very bad and poor
>>>english language :-)
>>>
>>
>>It's better than my Italian!
> 
> 
> ahahahah :-)
> 
> ciao ciao :-)
> 
>>Cheers,
>>Martin
>>
>>-- 
>>martin.j.thompson@trw.com
>>TRW Conekt, Solihull, UK
>>http://www.trw.com/conekt
> 
> 
> 
Hi Plenolo,

the Xilinx download cable has been discussed in a lot of threads in this group. 
The download cable is officially called "Parallel Cable III" by Xilinx. Search 
for this term on the their web site and you will get a lot of results including 
a link to the schematic. If you need only JTAG (sufficient for most cases) you 
can even simplify the design and go along with one 74HC125, some caps and 
resistors and a D-SUB connector.
Here at my university we've built lots of these cables and they all work fine.

Good luck,
Jens

------------ And now a word from our sponsor ----------------------
For a quality mail server, try SurgeMail, easy to install,
fast, efficient and reliable.  Run a million users on a standard
PC running NT or Unix without running out of power, use the best!
----  See http://netwinsite.com/sponsor/sponsor_surgemail.htm  ----

Article: 61698
Subject: Re: MICROBLAZE: Using external instruction memory
From: arkagaz@yahoo.com (arkaitz)
Date: 8 Oct 2003 23:37:49 -0700
Links: << >>  << T >>  << A >>
Thanks John,

Now, where can I find some information related to the "elf" extension
file? If I'm not wrong it's used in Linux, isn't it?

Just another question: I've been looking to the MicroBlaze's manual
but I haven't found anything about "mb-objcopy". Is it in the manual?

Thanks again for your help.

Arkaitz.

John Williams <jwilliams@itee.uq.edu.au> wrote in message news:<bm207h$4b3$2@bunyip.cc.uq.edu.au>...
> John Williams wrote:
> > Hi Arkaitz,
> > 
> > arkaitz wrote:
> > 
> >> I've done a flash loader but I don't know which file do I have to
> >> store in flash in order to enable to execute it.
> >>
> >> I've proved storing the "executable.elf" file which contains the
> >> crt0.o initialization code linked and then I jump to that address from
> >> a program stored in the Block RAMS, but as I supposed it doesn't work.
> > 
> > 
> > you must use mb-objdump utility to convert the elf file into an 
>                  ^^^^^^^^^
> 
> oops I meant objcopy of course!

Article: 61699
Subject: Re: More RPM / RLOC fun
From: Goran Bilski <goran@xilinx.com>
Date: Thu, 09 Oct 2003 08:58:22 +0200
Links: << >>  << T >>  << A >>
Hi Ray,

This is the reason I choose U_SET.

1. Not everything in a level might not go to the same SET but with H_SET 
EVERYTHING is forced into
    the same set.
2. I need very different floorplanning for different architectures.
3. I don't want to have my design hierarchical force to be the floorplan 
hierarchical.
    I like to divide my design into functional block independent of the 
floorplanning.
    ex. I have all my register file bits in the same vhdl file even if 
they are spread out in the floorplanning
    In one of the leafs in a branch of my design, I might need due to 
minimizing the routing delay from a primitive
    to another primitive in another leaf in a total different branch of 
the design.
    With H_SET, it a nightmare since I have to know all the relative 
placement of all H_SET
     from the first leaf to the top and then from the top to the another 
leaf.
     Whenever I change any of the relative placements, I have to check 
all the cross placement to see
      if they are effected.
     With the U_SET approach and all RLOC values in one function, I just 
need to change a value in the function and
      the placement is changed.

Göran

Ray Andraka wrote:

>Goran,
>
>I can't understand why you are working in flatland.  First off, it creates a bunch of
>
>extra typing.  If you use H_SETs, there is no need to explicitly declare each set, it
>
>is done automatically  for you, and then you can piece together the RLOCs without
>having to pass placement information into your lower levels.  Using USETs means
>you need a unique name for each instance of a macro, plus you need to compute the
>offsets for each and manually (in your code) add them to the RLOCs before applying
>the RLOCs.  With HSETs, that is all done automatically, so each module is truely
>standalone.  That means with HSETs you can compile parts of the code and then
>instance it as a black box in a higher level.  I'm not sure of the motivation for
>handling
>all the floorplanning in one place either.  Seems to me that the floorplanning should
>
>be with the module, as your layout normally will be the same regardless of where
>you put it. (I do have some with alternative layouts such as swapped horizontal, in
>which case I use generics to control the layout.  A simple case is whether the origin
>
>is at the top or the bottom of a carry chain, which is illustrated partly below).
>
>I handle the different RLOC strings for RC or XY grids by creating both strings and
>then using a pickstring function to select which gets used. Pickstring has an
>argument for the family
>(0=unplaced, 1= virtex/spartanII, 2=v2, 3=spartan3) plus an RC sting and an XY
>string.  In the
>case of unplaced, it returns the null string.  For 1 it returns the RC string, and
>for 2 or more the xy string
>For example:
> constant rc_str : string := "R" & itoa( origin -(i/2))  & "C0" & ".S" & itoa(slice
>mod 2);
> constant xy_str : string := "x0y" & itoa((i/2)-origin) ;
> constant rloc_str : string := pickstring(virtex,rc_str,xy_str);
> signal l,d,qr,qs: STD_LOGIC;
> attribute BEL of U1:label is bel_lut(i mod 2);
> attribute RLOC   of U1 : label is rloc_str;
>
>
>Is there some advantage of doing this flat that has totally escaped me?
>
>
>--
>--Ray Andraka, P.E.
>President, the Andraka Consulting Group, Inc.
>401/884-7930     Fax 401/884-7950
>email ray@andraka.com
>http://www.andraka.com
>
> "They that give up essential liberty to obtain a little
>  temporary safety deserve neither liberty nor safety."
>                                          -Benjamin Franklin, 1759
>
>
>  
>




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