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
Hi, I'd like to ask about setting a register upon power up to 1. Also I want that register to be reserve its value upon system reset. How can I do this operation from the logic design point of view and how to code it in VHDL Thanks Jamil KhatibArticle: 21901
If you e-mail JBits@xilinx.com then you should get more details. "Anshuman Sharma" <gte600f@prism.gatech.edu> wrote in message news:8cgmch$kd0@catapult.gatech.edu... > > does anyone know where I can get a copy of JBits? >Article: 21902
Hello, Is these warnings are valid: WARNING:OldMap:78 - All of the external outputs in this design are using slew-rate-limited output drivers. The delay on speed critical outputs can be dramatically reduced by designating them as fast outputs in the original design. Please see your vendor interface documentation for specific information on how to do this within your design-entry tool. Note: You should be careful not to designate too many outputs which switch together as fast, because this can cause excessive ground bounce. For more information on this subject, please refer to the IOB switching characteristic guidelines for the device you are using in the Programmable Logic Data Book. WARNING:OldMap:548 - All the logic for "HMAP symbol "HMAP_275" (output signal=syn15941)" has been removed! This may be caused by key logic being trimmed. Please consult the Removed Logic section of this report to see if this is the case. WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_69" (output signal=syn1528)" has been removed! This may be caused by key logic being trimmed. Please consult the Removed Logic section of this report to see if this is the case. WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_68" (output signal=syn1778)" has been removed! This may be caused by key logic being trimmed. Please consult the Removed Logic section of this report to see if this is the case. WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_67" (output signal=C81_N3)" has been removed! This may be caused by key logic being trimmed. Please consult the Removed Logic section of this report to see if this is the case. WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_66" (output signal=C82_N6)" has been removed! This may be caused by key logic being trimmed. Please consult the Removed Logic section of this report to see if this is the case. WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_277" (output signal=syn15940)" has been removed! This may be caused by key logic being trimmed. Please consult the Removed Logic section of this report to see if this is the case. WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_276" (output signal=syn16584)" has been removed! This may be caused by key logic being trimmed. Please consult the Removed Logic section of this report to see if this is the case. WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_274" (output signal=cell59)" has been removed! This may be caused by key logic being trimmed. Please consult the Removed Logic section of this report to see if this is the case. WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_254" (output signal=syn1508)" has been removed! This may be caused by key logic being trimmed. Please consult the Removed Logic section of this report to see if this is the case. WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_225" (output signal=syn16245)" has been removed! This may be caused by key logic being trimmed. Please consult the Removed Logic section of this report to see if this is the case. WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_153" (output signal=syn1553)" has been removed! This may be caused by key logic being trimmed. Please consult the Removed Logic section of this report to see if this is the case. And what mean this section: Primitive reference count: -------------------------- BUFG 1 CY4 9 CY4_25 7 CY4_27 1 CY4_42 1 DFF 23 FMAP 288 HMAP 41 IBUF 23 IFD 1 OFDX 1 With regards Tomek I request for reply on my e:mail: ---------------------------------- Tomasz Brychcy tbrychcy@sensor.ime.pz.zgora.pl ----------------------------------Article: 21903
rob_dickinson@my-deja.com wrote in message <8chjnj$6mu$1@nnrp1.deja.com>... >I have to disagree completely with this. The jtag spec was defined to >allow anything to be put on the chain by anyone. A decent tool >(software) will find out how many devices are on the chain and their >manufacturers id and how "long" each device is. Its fairly >straightforward to make a device on the chain transparent (via >software), allowing debuggers (for instance) to get to one device >without having to keep clocking data through an enormous shift register >(the other devices). I am fairly certain that the AD debugger turns >off the other SHARCS in the chain to debug the SHARC of interest. > >I "watched" a software engineer doing boundary scan with tcl about 3 >years ago and I simply remember a passing comment that AD had not quite >kept to the letter of the JTAG spec in terms of the id it returns. I >used the same JTAG path to just ISP the machs and the SHARCS ( and some >JTAG quickswitches etc) got "out of the way" just fine. > >My original post said that the SHARC "hardware implementation is >correct" as the original guy was questioning his hardware. I expect >that the XILINX jtag kit can't quite cope with the SHARC which has bent >the JTAG rules, allthough MACHPRO (the mach JTAG ISP software) could. > >Rob I just said that i "believed" that it was a software problem, in fact, i'm not sure of this. As we found a simple solution, (splitting the chain), and as it was difficult to get a good support about this problem (for Xilinx the problem is due to AD and for AD it's due to Xilinx ;-)) ) we didn't investigate too far. J-P GOGLIO GETRIS S.A. 13 Chemin des Prés 38240 Meylan Tel : (33) 4 76 18 52 10 E-mail : goglio@getris.com Fax : (33) 4 76 18 52 01Article: 21904
Spliting the chain worked in my case as well. Thanks. G.Article: 21905
rob_dickinson@my-deja.com writes: > I have to disagree completely with this. The jtag spec was defined to > allow anything to be put on the chain by anyone. A decent tool > (software) will find out how many devices are on the chain and their > manufacturers id and how "long" each device is. Its fairly > straightforward to make a device on the chain transparent (via > software), allowing debuggers (for instance) to get to one device > without having to keep clocking data through an enormous shift register > (the other devices). I am fairly certain that the AD debugger turns > off the other SHARCS in the chain to debug the SHARC of interest. The PowerPC debugger RiscWath requires the PowerPC to be alone in the JTAG chain. Quite stupid. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 21906
Hello Grzegorz,
Grzegorz wrote:
> I've got six devices in JTAG chain. 3 x Xilinx XLA 4000 series, AMD DSP
> proc, 2x Xilinx 9500 series.
> Everything looks OK, init is low, bsd files are correct and I get such an
> error:
<snip snip>
> Did anyone see such a problem? What it could be ?
> Another thing is: what else could I do to narrow the problem down ?
I have used JTAG Programmer with other components than those from Xilinx, and I
haven't encountered problems yet. The key is to make sure the BSDL files are OK
(and often they're not) and will be understood correctly by the software. Before
executing any JTAG-related instruction, the software must parse the BSDL file
and find out how to place third-party devices in BYPASS.
I have no experience with the mentioned DSPs, but I took the liberty of looking
at the BSDL file of an ADSP-21160 and I found out that it lacks the "attribute
REGISTER_ACCESS of <component>" statement, because all its publicly-accessible
instructions are instructions that have target register *implicitly* defined by
the standard (and that's permitted).
Since all Xilinx components have the REGISTER_ACCESS statement in their BSDL
files and since they even define target registers for the standard instructions,
it is possible that JTAG Programmer expects to find this keyword.
I would thus suggest to add the following text at its appropriate location (that
is, just before the BOUNDARY_LENGTH attribute):
attribute REGISTER_ACCESS of <DSP_component_name_goes_here> : entity is
"BYPASS (BYPASS)," &
"BOUNDARY (SAMPLE,EXTEST,INTEST)";
Also, I am not sure that the following BSDL statement is valid:
attribute BOUNDARY_CELLS of ADSP_21160: entity is
"BC_1, BC_2, BC_3, BC_4";
-- BC_1: output, control; BC_2: input; BC_3: internal; BC_4: clock;
Which may be present in *your* BSDL file (it is in the BSDL for the 21160);
since it may confuse the software, I would suggest to delete it. Then save the
modified BSDL under another name, tell JTAG Programmer to use it instead and see
if it loads/executes correctly.
Hope it helps,
Étienne.
--
______ ______
*****/ ____// _ \_\*************************************************
* / /_/_ / /_/ / / Etienne Racine, Hardware Designer *
* / ____// __ /_/ Visual Systems Engineering *
* / /_/_ / / /\ \ \ CAE Electronics Ltd. *
*/_____//_/_/**\_\_\*************************************************
Article: 21907You can parse and edit the INIT= strings in the EDIF file if you feel adventurous. I haven't done it thru the edif, but I had done that thru the old XNF format. In that case it was to initialize a bunch of LFSR counters with unique values. They were implemented in LUT RAM in a 4K device. It wasn't that hard to do. I think the EDIF would be perhaps a little harder, but not much. You could probably write a perl script to do it. Janos Ero wrote: > Ray Andraka wrote: > > > > You need to get the data into the VHDL one way or another. > <snip> > > library ieee; > > use ieee.std_logic_1164.all; > > package parameters is > > type TABLE_TYPE is array (NATURAL range <>) of integer; > > constant EXP_LUT: TABLE_TYPE:= ( > > 5918491, 5721208, 5523925, 5326641, 5129358, 4932075, 4734792, 4537509, -- 0:7 > > Hm, actually I wanted to avoid exactly this. > This means I have to reformat all my LUTs > and they are numerous :-( > > For me an ideal solution would be to open > "empty" ROMs and fill them at fitting, as > it happens when developing in the AHDL way. > > Thanks for the hints. > > Janos Ero -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21908
So does the Raven Wiggler. We had to resort to separate chains on a recent project as well. Magnus Homann wrote: > rob_dickinson@my-deja.com writes: > > > I have to disagree completely with this. The jtag spec was defined to > > allow anything to be put on the chain by anyone. A decent tool > > (software) will find out how many devices are on the chain and their > > manufacturers id and how "long" each device is. Its fairly > > straightforward to make a device on the chain transparent (via > > software), allowing debuggers (for instance) to get to one device > > without having to keep clocking data through an enormous shift register > > (the other devices). I am fairly certain that the AD debugger turns > > off the other SHARCS in the chain to debug the SHARC of interest. > > The PowerPC debugger RiscWath requires the PowerPC to be alone in the > JTAG chain. Quite stupid. > > Homann > -- > Magnus Homann, M.Sc. CS & E > d0asta@dtek.chalmers.se -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21909
Nope, It's not only temp dependent, it is also process and voltage dependant. It's main function is to provide the internally generated configuration clock. They were just nice enough to make it available for a cheap and dirty logic clock too. bjorn_lindegren@my-deja.com wrote: > Using Spartan XCS10-PC84, when I read the manual for this FPGA, I found > that the on chip oscillator falls between 10 Mhz and 4 Mhz. > > I want to use this oscillator to determine a frequens, and I need a > constant oscillator. Is it possible to use this on chip oscillator in a > lower mode or do I have to use an extern oscillator. > > In other words, is it possible to do the on chip oscillator temperatur > undependent? > > Thankful for help > > Björn Lindegren > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21910
Tomasz Brychcy wrote: > Hello, > > Is these warnings are valid: > WARNING:OldMap:78 - All of the external outputs in this design are using > slew-rate-limited output drivers. The delay on speed critical outputs > can be > dramatically reduced by designating them as fast outputs in the original > design. Please see your vendor interface documentation for specific > information on how to do this within your design-entry tool. > Note: You should be careful not to designate too many outputs which > switch > together as fast, because this can cause excessive ground bounce. For > more > information on this subject, please refer to the IOB switching > characteristic > guidelines for the device you are using in the Programmable Logic Data > Book. This one just means that you used the default slow IO, which is often fine. Depends on your application. Part of your design got optimized out. It looks like it is a floorplanned design, and seeing that you are not familiar with the warning messages, I guessing that these are not your floorplanning, rather it is part of a logic core. These warnings indicate that the mapper optimized out part of your logic. In this case, it looks like all that was removed are the floorplanning components which tell how the design is to be mapped into LUTs. Most likely, one or more of the inputs to these LUTs was tied to VCC or GND in your design. The mapper optimizes the design by removing unused outputs, combining CLBs that are not FMAP'd, absorbing inverters and buffers and removing grounded/pulled up inputs to logic. THere is another section of the map report that will tell you what logic got optimized, from there you can figure out what got stripped out. > > WARNING:OldMap:548 - All the logic for "HMAP symbol "HMAP_275" (output > signal=syn15941)" has been removed! This may be caused by key logic > being > trimmed. Please consult the Removed Logic section of this report to see > if > this is the case. > WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_69" (output > signal=syn1528)" has been removed! This may be caused by key logic being > trimmed. Please consult the Removed Logic section of this report to see > if > this is the case. > WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_68" (output > signal=syn1778)" has been removed! This may be caused by key logic being > trimmed. Please consult the Removed Logic section of this report to see > if > this is the case. > WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_67" (output > signal=C81_N3)" has been removed! This may be caused by key logic being > trimmed. Please consult the Removed Logic section of this report to see > if > this is the case. > WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_66" (output > signal=C82_N6)" has been removed! This may be caused by key logic being > trimmed. Please consult the Removed Logic section of this report to see > if > this is the case. > WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_277" (output > signal=syn15940)" has been removed! This may be caused by key logic > being > trimmed. Please consult the Removed Logic section of this report to see > if > this is the case. > WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_276" (output > signal=syn16584)" has been removed! This may be caused by key logic > being > trimmed. Please consult the Removed Logic section of this report to see > if > this is the case. > WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_274" (output > signal=cell59)" has been removed! This may be caused by key logic being > trimmed. Please consult the Removed Logic section of this report to see > if > this is the case. > WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_254" (output > signal=syn1508)" has been removed! This may be caused by key logic being > trimmed. Please consult the Removed Logic section of this report to see > if > this is the case. > WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_225" (output > signal=syn16245)" has been removed! This may be caused by key logic > being > trimmed. Please consult the Removed Logic section of this report to see > if > this is the case. > WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_153" (output > signal=syn1553)" has been removed! This may be caused by key logic being > trimmed. Please consult the Removed Logic section of this report to see > if > this is the case. > > And what mean this section: This section tells you what logic is in the mapped design > > > Primitive reference count: > -------------------------- > BUFG 1 -1 global clock buffer > CY4 9 -9 carry logic primitives > CY4_25 7 -these are the carry logic control primitives, one > per CY4. 42 is the msb "examine". > CY4_27 1 i don't recall off the top of my head what 27 > and 25 are: I think they may be decrements. 27 > CY4_42 1 is the one for the lsb, and 25 is probably > FG-CI meaning it is two bits with carry in > DFF 23 --23 D flip-flops > FMAP 288 -288 F/G 4 input generators > HMAP 41 -41 H 3 input generators > IBUF 23 -23 input pins (not registered) > IFD 1 -1 registered input > OFDX 1 -1 registered tristate output > > With regards > > Tomek > > I request for reply on my e:mail: > ---------------------------------- > Tomasz Brychcy > tbrychcy@sensor.ime.pz.zgora.pl > ---------------------------------- -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21911
I have Win/NT 4 with service pack 6a and have no problem running CoreGen! +------------------------------Disclaimer------------------------------+ | This message is my personal opinion and does not represent | | the position of SpaceBridge Networks Corporation. | +-----------------------------------+----------------------------------+ | Name: Amal Khailtash | Co.: SpaceBridge Networks Corp. | | Title: Hardware Developer | (A Com Dev/NewBridge Company) | | Email: akhailtash@spacebridge.com | Tel: +1 (819) 776-5664 x.6183 | | URL: http://www.spacebridge.com | +1 (819) 776-2848 x.6183 | | Addr.: 115 Champlain Street | Fax: +1 (819) 776-4179 | | Hull, PQ J8X 3R1, Canada | | +-----------------------------------+----------------------------------+ Steve <reply.through.newsgroup@paranoid.com> wrote in message news:pB8E4.41100$pA.126638@typhoon.mbnet.mb.ca... > I have recently tried coregen for the first time, and keep getting > java errors and internal errors. I tried on 2 NT SP6 machines > and one Windows 2000 machine. > > I've just been told that there might be a problem with SP6. > Has anyone else seen this? > > > Steve > > >Article: 21912
After the recent thread on FPGA openness (ie. the bitstream formats) I decided to put together a more permanent summary before the thread vanished from newservers. You can see it at: http://collector.hscs.wmin.ac.uk/news/ It's a biased summary, in the sense that I agree with the 'bitstream should be open' side of the argument. But I've tried to be careful not to quote the people on the other side of the argument out of context. If anyone does feel I've misrepresented them by taking statements out of context, let me know. GrahamArticle: 21913
Jamil Khatib wrote in message <38EC562E.92160F8F@ieee.org>...
>Hi,
>I'd like to ask about setting a register upon power up to 1.
>
>How can I do this operation from the logic design point of view and how
>to code it in VHDL
Power-on set? How about:
reg : process (clk, reset) is
begin
if reset = '1' then
q <= '1';
elsif rising_edge(clk) then
q <= d;
end if;
end process reg;
>Also I want that register to be reserve its value upon system reset.
I'm not sure what you mean by this ...
--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"Money is property; it is not speech."
-- Justice John Paul Stevens
Article: 21914Speaking of JTAG problems... We have a board with a Xilinx XCV400 and an Altera 7064. The Altera JTAG programming software is unable to program the '7064 unless a configuration bitstream has already been loaded into the XCV400 (which we normally do using serial configuration mode indirectly over a PCI bus). The XCV400 sits there with its TDO pin "stuck high," it appears, until it's configured. This isn't really a problem for us, but I'm curious if anyone knows off-hand what might be causing it. We have another board that has a TI 'C549 DSP, Vantis Mach111SP, Altera 7032, and Cypress 37128 all in the same JTAG chain. All the vendors' software was able to successfully place every other vendor's part into bypass mode. I was impressed. ---Joel KolstadArticle: 21915
Hi Joel,
Joel Kolstad wrote:
> We have a board with a Xilinx XCV400 and an Altera 7064. The Altera JTAG
> programming software is unable to program the '7064 unless a configuration
> bitstream has already been loaded into the XCV400 (which we normally do
> using serial configuration mode indirectly over a PCI bus). The XCV400 sits
> there with its TDO pin "stuck high," it appears, until it's configured.
Could it be that the PROG* pin is left low until you're ready to program the
XCV400? In its Virtex BSDLs, Xilinx says:
-- The boundary scan test vectors must keep the PROGRAM_B pin
-- either 3-stated or driving high. If the PROGRAM_B pin is
-- driven low through any means, the TAP controller will reset.
And of course, you *don't* want to reset the TAP state machine (I suppose it's
asynchronous).
Étienne.
--
______ ______
*****/ ____// _ \_\*************************************************
* / /_/_ / /_/ / / Etienne Racine, Hardware Designer *
* / ____// __ /_/ Visual Systems Engineering *
* / /_/_ / / /\ \ \ CAE Electronics Ltd. *
*/_____//_/_/**\_\_\*************************************************
Article: 21916Hi, I'm trying to take a completed .BIT file and, using JTAG Programmer, create an .SVF file. JTAG Programmer complains about no BSDL file for the Spartan II device (I'm using an XC2S100PQ208). Does anyone have a set of BSDL files for these new devices??? Also, for the same reason, I cannot use JTAG programmer with the Parallel III cable to program my part over JTAG. My main objective is to create an SVF file and then a XSVF file so that I can configure the SPartan II device as described in XAPP058 (via a microcontroller). All help appreciated, GBArticle: 21917
This is a multi-part message in MIME format. --------------F78CED9B4A4390364724FAD9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Keith R. Williams" wrote: > > On Wed, 5 Apr 2000 14:20:49, Utku Ozcan <ozcan@netas.com.tr> > wrote: > > > Can you recommend any bridge through which Motorola's > > 860 or 8240 processors can control XCV*E FPGAs? There > > will be many Virtex-E devices on the board, like 10. > > FPGA's CPU Interface will communicate to this Bridge. > > Or is there any better newsgroup to direct this q? > > I'm using the PLX PCI9054. It is a full PCI master and quite > cheap (well compared to a Virtex-E). I think the boss paid about > $30 for the BG256 part in small quantities. [snip] > I wouldn't bother using a PCI core on an expensive part like the > Virtex-E. I started down this road (not with Xilinx) and it was > a huge mistake. Agreed, the FPGA real-estate is too valuable to waste on PCI, unless board space is even more valuable. I don't know how well it plays with the PPC, but I'm using the Intel i960VH I/O processor in my current design. The part is ~$6, but requires RAM as well. It is useful to have a medium performance processor to handle control functions associated with moving data over PCI bus, although must now write i960 code. --------------F78CED9B4A4390364724FAD9 Content-Type: text/x-vcard; charset=us-ascii; name="jsmith.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for John L. Smith Content-Disposition: attachment; filename="jsmith.vcf" begin:vcard n:Smith;John L. tel;work:858-320-4102 x-mozilla-html:FALSE url:http://www.visicom.com org:Visicom;Imaging Products adr:;;10052 Mesa Ridge Court;San Diego;CA;92121;USA version:2.1 email;internet:jsmith@visicom.com title:Principal Engineer x-mozilla-cpt:;30864 fn:John L. Smith end:vcard --------------F78CED9B4A4390364724FAD9--Article: 21918
Nice job on the summary! Also on the rest of the site news - very good open tech coverage. regards, tom Graham Seaman wrote: > > After the recent thread on FPGA openness (ie. the bitstream formats) > I decided to put together a more permanent summary before the > thread vanished from newservers. > You can see it at: http://collector.hscs.wmin.ac.uk/news/ -- Tom Burgess -- Digital Engineer Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.caArticle: 21919
Hi Jaime,
Have you considered the userid register in the Virtex/Spartan-II devices? It is
a dedicated 32 bit register accessible via the JTAG TAP and the value is set at
bitgen (the final step in implementation). It would be possible to write a
script to automatically calculate a value to be placed in that register by
invoking bitgen with the request.
More information about this register can be found in xapp139.
http://support.xilinx.com/xapp/xapp139.pdf
or by typing bitgen -help virtex at the command line.
Robert Binkley
Xilinx Applications
Jamie Sanderson wrote:
> I just wanted to thank everyone for the helpful suggestions. What I'm
> hearing doesn't particularly fill me with hope, but they are good solutions
> nonetheless. My next move will be to contact Xilinx and see whether or not
> they wouldn't be willing to give the problem to one of their people. I'll be
> sure to post my progress here.
>
> Best regards,
> Jamie
>
> <eml@riverside-machines.com.NOSPAM> wrote in message
> news:38dc9056.269070770@news.dial.pipex.com...
> > I'd like to do this as well, so it would be interesting to hear how
> > you get on. I can't see that you'll get the GUI version/revision info
> > though, since this is just private to the GUI. Why don't you just
> > maintain a revision register in your device? Your problem then is just
> > identifying this register, or the serial number register, in the
> > bitfile.
> >
> > I haven't looked at Jbits but, if it doesn't do the job, this
> > procedure might work. Have a 16-bit revision number implemented as a
> > CLB ROM element, and locate this ROM at a known CLB location. Generate
> > an 'll' file from Bitgen ('-l' option). Search the ll file for lines
> > containing your known CLB location (the ll format is documented in the
> > file). This will give you the bit number, frame number, and frame
> > offset for all 16 bits in your ID. The trick now is to identify these
> > bits in your bitfile; see xapps 138 and/or 151.
> >
> > As an aside, this is what I do to get around the Xilinx GUI
> > revision/version structure. My rebuild makefile always builds in a
> > fixed directory (xproj/current in my setup), and you rely on a source
> > control system to retrieve the important files (only) from previous
> > builds. You then don't need multiple directories to keep a huge amount
> > of redundant information.
> >
> > Evan
> >
Article: 21920Nice summary. One nit on your conclusion though, You mention that several tools generate the XNF format, which is true enough. What is implied though is that that gets you closer to the bitstream. XNF is the netlist that goes into the front end of the tool- it is basically a textual netlist of your schematic or HDL design. In the M1 and M2 tools, EDIF format is preferred by xilinx, and they've made noises about getting rid of XNF altogether (which us users have asked them not to do). As I mentioned fairly early in the thread, you can get pretty detailed in your description of the design at the XNF level in that you can direct placement as well as lock the pins on the CLBs to force a particular routing. The fact is though, that XNF is the file format to get into the front end of the tools, not a shortcut to the backend. Graham Seaman wrote: > After the recent thread on FPGA openness (ie. the bitstream formats) > I decided to put together a more permanent summary before the > thread vanished from newservers. > You can see it at: http://collector.hscs.wmin.ac.uk/news/ > It's a biased summary, in the sense that I agree with the > 'bitstream should be open' side of the argument. But I've > tried to be careful not to quote the people on the other side > of the argument out of context. If anyone does feel I've misrepresented > them by taking statements out of context, let me know. > > Graham -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21921
On Thu, 6 Apr 2000 18:42:50, "John L. Smith" <jsmith@visicom.com> wrote: > This is a multi-part message in MIME format. > "Keith R. Williams" wrote: > > I'm using the PLX PCI9054. It is a full PCI master and quite > > cheap (well compared to a Virtex-E). I think the boss paid about > > $30 for the BG256 part in small quantities. > [snip] > > I wouldn't bother using a PCI core on an expensive part like the > > Virtex-E. I started down this road (not with Xilinx) and it was > > a huge mistake. > > Agreed, the FPGA real-estate is too valuable to waste on PCI, > unless board space is even more valuable. > > I don't know how well it plays with the PPC, but I'm using the > Intel i960VH I/O processor in my current design. The part is > ~$6, but requires RAM as well. It is useful to have a medium > performance processor to handle control functions associated > with moving data over PCI bus, although must now write i960 code. Actually I have *SNAIL* running the card. The processor running the card is an *OLD* Intel 8051 variant (12MHz and 12 cycles per instruction). The PPC is only there because it is the whole point of the project. ;-) Note that I'm not using a Virtex-E for an 8051. There is also a bunch of 2.5ns DDR SRAM on the card. Even though I'm not using the features, the PLX chips are very PPC friendly. As I said, the IOP480 has a PPC 503(I think) built in. The PCI9054 has a PPC860 mode. In any case, I cannot see any reason to use prime Virtex space for PCI. I went down this road and got burned big time. BTW. the $30 price on the PLX chip was for one (ok, twenty) BGA256. Next to the grand+ the Virtex costs, I could care less. ---- KeithArticle: 21922
Sorry for the mistake in my very first mail. Actually on the board there will be BOTH the 860 and 8240 processors. The reason why we have chosen both of these is backward compatibility. That Virtex-E devices don't have PCI interfaces at a first glance is also because of backward compatibility. Keith, thank you very much for the site you have given me. But although the backward compatibility makes our mind busy, PCI core also seems to be attractive. We are paying attention to experiences around. Utku -- I feel better than James Brown.Article: 21923
can anyone guide me to the EHW conference website?
--
---------------------------------------------------
"time and space are modes by which we think...... |
they are not the conditions in which we live." |
|
~~Einstein |
---------------------------------------------------
Anshuman Sharma
Georgia Institute of Technology, Atlanta Georgia, 30332
Email: gte600f@prism.gatech.edu
anshu@abraxis.com
Article: 21924In article <38EC562E.92160F8F@ieee.org>, khatib@ieee.org wrote: > Hi, > I'd like to ask about setting a register upon power up to 1. > Also I want that register to be reserve its value upon system reset. > > How can I do this operation from the logic design point of view and how > to code it in VHDL > > Thanks > > Jamil Khatib > > If I understand you correctly you want a FF which on power on starts with in a defined state, but is not affected by subsequent reset's. This is not possible with every device. One family where it will work is the XC9500 from Xilinx, since they are FlashROM based and initialize at power on. You can specify an initial value in the UCF file. If you can do this from VHDL depends on your compiler. Generally initial values are ignored by synthesis. You have to specify an INIT attibute for the signal, and the compiler will pass this information to the fitter. To ignore the systems reset simply do not connect this to the FF. In principle this should alos work for a SRAM based device, but it depends if it is reinitialized (reloaded from PROM) on a reset. Hope this helps -- Klaus Falser Durst Phototechnik AG I-39042 Brixen Sent via Deja.com http://www.deja.com/ Before you buy.
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