Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
"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
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.ukArticle: 61677
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 ProvidenzaArticle: 61678
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-64Article: 61679
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, JohnArticle: 61680
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: 61681My 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
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
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
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: 61685I 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 cputimeArticle: 61686
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
"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
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
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
> 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
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
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: 61693Hi 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? JakeArticle: 61694
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. JonArticle: 61695
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 AlteraArticle: 61696
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
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
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
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:
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