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
Antti, The MGT's are designed to address the same standards as V2 Pro and V2 Pro X. That said, the ppm frequency shift of SATA when using spread spectrum clocking (0 to -5000 ppm)is not addressed. Austin Antti Lukats wrote: > "Austin Lesea" <austin@xilinx.com> wrote in message > news:ci4p3r$imf1@cliff.xsj.xilinx.com... > >>All, >> >>As Peter would say, the teasing is over: V4 is ALIVE. >> >>http://www.xilinx.com for all of the details. >> >>Now I can finally talk about it. >> >>Austin > > > Any ideas if the V2 rocket MGTs are any better ? > int terms of tolerance to lock freq ppm window and to be able to support > more standards? > > Antti > >Article: 73126
Dan K wrote: > "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message (snip) > A while back I was deposed for a patent infringement law suit. > The opposition lawyer were trying to prove that my > "hardware search engine" built in an FPGA was really a > "software search engine" because anything in an FPGA was > really software. Don't know how that one turned out as I'm no > longer with that company, > but: Lawyers - ya gotta love em! In the days when software wasn't patentable and hardware was, the distinction was important. There were stories about the patent for virtual memory, being both hardware and software and the problems trying to patent it. Yes, the distinction is only important to lawyers. -- glenArticle: 73127
Is seems the TIOPI only 1.20 - 0.31 = 0.89ns for LVTTL input described in SP-3 datasheet v1.3, and the TIOOP for LVTTL F12 is 3.42-0.12 = 3.2ns. "Robert Sefton" <rsefton@abc.net> дÈëÓʼþ news:2qn4qtF111ef9U1@uni-berlin.de... > Can someone explain this to me? > > Here's the LVTTL I/O timing for Virtex-2 -4 and Spartan-3 -4 (Fast 12mA > drive for the outputs): > > Virtex-2 Spartan-3 > -------- ---------- > TIOPI 0.88ns 2.15ns (pad to IOB .I output) > TIOOP 1.74ns 0.48ns (IOB ,O input to pad) > > According to these numbers the Spartan-3 input buffer got 1.27ns slower and > the output buffer got 1.26ns faster. Is this possible? > > I have a Virtex-2 1000 design that fits perfectly in a Spartan-3 1000, but I > just routed it and got a ton of input path timing errors. So much for saving > $125 per chip with S3. > > Thanks, > Rob > (email is bogus, please reply to group) > >Article: 73128
"Channing Wen" <channing@pldsupport.com> wrote in message news:ci7a1g$1o0i$1@mail.cn99.com... > Is seems the TIOPI only 1.20 - 0.31 = 0.89ns for LVTTL input described in > SP-3 datasheet v1.3, and the TIOOP for LVTTL F12 is 3.42-0.12 = 3.2ns. > Channing - Are you looking at Tables 16 and 17 for the input delay and Tables 18 and 20 for the output delay? I still get 2.15ns for the input delay (1.94 + 0.21), but I had the output delay wrong. 0.48ns is just the correction factor for LVTTL F12. The complete output delay is 1.46 - 0.48 = 0.98ns. Where did you get your numbers? Thanks, RobArticle: 73129
"Robert Sefton" <rsefton@abc.net> wrote in message news:2qn4qtF111ef9U1@uni-berlin.de... > Can someone explain this to me? > > Here's the LVTTL I/O timing for Virtex-2 -4 and Spartan-3 -4 (Fast 12mA > drive for the outputs): > > Virtex-2 Spartan-3 > -------- ---------- > TIOPI 0.88ns 2.15ns (pad to IOB .I output) > TIOOP 1.74ns 0.48ns (IOB ,O input to pad) > > According to these numbers the Spartan-3 input buffer got 1.27ns slower and > the output buffer got 1.26ns faster. Is this possible? > > I have a Virtex-2 1000 design that fits perfectly in a Spartan-3 1000, but I > just routed it and got a ton of input path timing errors. So much for saving > $125 per chip with S3. Do you know which version of the speeds file you are using? It should be listed in the timing report. Alternately, you can type the following on the command line or in a DOS box. speedprint 3s1000 > timing.txt The "version id" is listed toward the top of the file. You want v1.32 or later. The numbers in your posting don't seem to match up completely with the v1.32 speeds file or the Spartan-3 data sheet, even with the relevant adjustments to LVTTL. Here are the values from the Spartan-3 data sheet. http://www.xilinx.com/bvdocs/publications/ds099-3.pdf Tiopi = 1.94 ns (measured for LVCMOS, 2.5V, 12 mA output drive, Fast slew rate) LVTTL input adjustment = 0.21 ns Tiopi (LVTLL) = 1.94 + 0.21 = 2.15 ns Tioop = 1.46 ns LVTTL output adjustment = 0.48 ns Tioop (LVTTL) = 1.46 + 0.48 = 1.94 ns There is a physical reason for some I/O timing differences between Virtex-II and Spartan-3. Spartan-3 uses lower cost wire-bonded packages and has a dual I/O ring. What is the nature of you input path timing errors? What timing do you need? Perhaps there is a relatively easy work-around. The Digital Clock Managers (DCMs) on a Spartan-3 FPGA allow you to adjust I/O timing if you have a monotonic clock. If the clock is not monotonic, you can also use a technique that Xilinx calls "local clocking". We use this on a number of high-speed memory interfaces. "Saving $125 per chip with S3", I hope, justifies a little further analysis. ;-) --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/II/IIE FPGAs http://www.xilinx.com/spartan3 --------------------------------- Spartan-3: Make it Your ASICArticle: 73130
I'll suggest again the latest EDK service pack. Paul Mancini Stephane wrote: > > Thanks a lot, > Yes but my version allow me only to have PLB slave. > What I'm wondering is if the IPIF PLB master is OK despite the fact that > the EDK IP Import Wizard doesn't have the feature. > The problem is that it will be long until we have the new version... > > Can I use the IPIF PLB master with EDK 6.2 with no problem ? > > I can hack the slave only version to use a master but it would be easier > if someone could give me a VHDL wrapper with a single master. > Thanks a lot for your help. > > Stephane > > On Mon, 13 Sep 2004 11:44:15 -0700, Paul Hartke wrote: > > > Have you considered the EDK IP Import Wizard? > > > > I see that you are are not using the latest EDK service pack. There are > > more features in this area in EDK 6.2.2 > > > > EDK 6.3 should be coming out shortly, and I figure there will be more > > additions in there as well. > > > > Paul > >Article: 73131
Hello Every1, I am looking for VHDL code for a serial port. Small. Fixed Baud rate. Perhaps only output, don't know that for sure yet. I look at XAPP699 and started to think that the real code isn't really there, just an IP core with various wrappers and test benches. Not sure about this. Could anybody point the way here? Much obliged, Brad b r a d @ a i v i s i o n . c o mArticle: 73132
"Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com> wrote in message
news:ci7b93$9rd1@cliff.xsj.xilinx.com...
>
> Do you know which version of the speeds file you are using? It should be
> listed in the timing report. Alternately, you can type the following on
> the
> command line or in a DOS box.
>
> speedprint 3s1000 > timing.txt
>
> The "version id" is listed toward the top of the file. You want v1.32 or
> later.
Steve -
Thanks for the reply. Here's the speed file version from the timing report:
Device,speed: xc3s1000,-4 (ADVANCED 1.32 2004-06-09)
> The numbers in your posting don't seem to match up completely with
> the v1.32 speeds file or the Spartan-3 data sheet, even with the relevant
> adjustments to LVTTL. Here are the values from the Spartan-3 data sheet.
> http://www.xilinx.com/bvdocs/publications/ds099-3.pdf
>
> Tiopi = 1.94 ns (measured for LVCMOS, 2.5V, 12 mA output drive, Fast slew
> rate)
> LVTTL input adjustment = 0.21 ns
> Tiopi (LVTLL) = 1.94 + 0.21 = 2.15 ns
>
> Tioop = 1.46 ns
> LVTTL output adjustment = 0.48 ns
> Tioop (LVTTL) = 1.46 + 0.48 = 1.94 ns
>
I was working from the data sheet. I got Tiopi right but butchered Tioop
twice. When I use the tables correctly I get 1.94ns. So the S-3/V-2 (-4)
comparison looks like this now for LVTTL F12:
Virtex-2 Spartan-3
-------- ----------
TIOPI 0.88ns 2.15ns (pad to IOB .I output)
TIOOP 1.74ns 1.94ns (IOB .O input to pad)
This is a huge hit to take on the input path. My Virtex-2 design interfaces
to a PowerPC and SDRAM on a 66MHz 60X bus, and there's also flash
and a couple of peripherals on the bus. The FPGA is a bus master for SDRAM
DMAs, and the I/O timing for the ciritcal arbitration and control signals is
extremely tight. They can't be registered in the IOB. I'm already using the
DCM.
> There is a physical reason for some I/O timing differences between
> Virtex-II
> and Spartan-3. Spartan-3 uses lower cost wire-bonded packages and has a
> dual I/O ring.
>
> What is the nature of you input path timing errors? What timing do you
> need? Perhaps there is a relatively easy work-around. The Digital Clock
> Managers (DCMs) on a Spartan-3 FPGA allow you to adjust I/O timing if you
> have a monotonic clock. If the clock is not monotonic, you can also use a
> technique that Xilinx calls "local clocking". We use this on a number of
> high-speed memory interfaces.
>
Here's one of my input timing constraints:
NET "abb_n_pad" OFFSET = IN 7.1 ns AFTER "clk66_pad"; (7.1ns is the PowerPC
derated output delay + trace delay + fudge for clock skew)
Here's the result in Virtex-2:
================================================================================
Timing constraint: COMP "abb_n_pad" OFFSET = IN 7.100 nS AFTER COMP
"clk66_pad" ;
50 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold
errors)
Maximum allowable offset is 7.380ns.
--------------------------------------------------------------------------------
So Virtex-2 makes the constraint with 280ps margin.
Here's the Spartan-3 result:
================================================================================
Timing constraint: COMP "abb2_n_pad" OFFSET = IN 7.100 nS AFTER COMP
"clk66_pad" ;
13 items analyzed, 7 timing errors detected. (7 setup errors, 0 hold
errors)
Maximum allowable offset is 5.637ns.
--------------------------------------------------------------------------------
So the Spartan-3 misses by 7.1 - 5.637 = 1.463ns. That's pretty close to the
1.27ns
increase in the input buffer delay. The rest is lost in the internal logic,
which is also slower
in Spartan-3. Here are the internal 66MHz timing results:
Virtex-2:
================================================================================
Timing constraint: TS_clk66_dll_clk0 = PERIOD TIMEGRP "clk66_dll_clk0"
TS_CLK66 * 1.000000 HIGH
50.000 % ;
59785 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold
errors)
Minimum period is 11.770ns.
--------------------------------------------------------------------------------
Spartan-3:
================================================================================
Timing constraint: TS_clk66_dll_clk0 = PERIOD TIMEGRP "clk66_dll_clk0"
TS_CLK66 * 1.000000 HIGH
50.000 % ;
59860 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold
errors)
Minimum period is 13.694ns.
--------------------------------------------------------------------------------
So the Spartan-3 is about 15% slower than Virtex-2 internally. I'm pretty
bummed with
these results. The Spartan-3 pricing is compelling, but just a tease if it
can't make timing.
And I need the industrial temp range, so I can currently only use -4 parts.
I'm open to any and all ideas, but I can't speed up the PowerPC so Spartan-3
looks like
a no-go on this one.
Thanks,
Rob
Article: 73133I'm very new to working with Xilinx tools so I may be overlooking something obvious. I'm able to synthesize with XST and simulate using Modelsim without any problems. But I am unable to implement my design because a Coregen ROM generates errors in the translate step. The ERROR messages don't seem to be indicative of the problem. I've tried referring to the Xilinx online help but it has been most unhelpful. Has anyone run into these ERRORS before? 1) ERROR:NgdBuild:76 - File "c:\xilinx\rtc2/ro256x8pre.ngc" cannot be merged into block "rom0_rom0" (TYPE="ro256x8pre") because one or more pins on the block, including pin "CLK", were not found in the file. Please make sure that all pins on the instantiated component match pins in the lower-level design block (irrespective of case). If there are bussed pins on this block, make sure that the upper-level and lower-level netlists use the same bus-naming convention. The Xilinx Answer Record #14848 says to change the bus delimiter style of the synthesis tool to match the bus macro style. But they already agree, so I shouldn't have to change anything. Also, I've made sure that all port names match. 2) ERROR:NgdBuild:604 - logical block 'rom0_rom0' with type 'ro256x8pre' could not be resolved. A pin name misspelling can cause this, a missing edif or ngc file, or the misspelling of a type name. Symbol 'ro256x8pre' is not supported in target 'virtex2'. This one has me at a loss. These files are auto-generated by Coregen so it leaves very little room (or so I thought) for me to screw things up. Any help would be greatly appreciated. thanks, JonArticle: 73134
Brad, The PicoBlaze reference design comes with VHDL code to implement a serial port. You can download the PicoBlaze design with the serial port code after registering at: http://www.xilinx.com/picoblaze Cheers, Shalin- Brad Smallridge wrote: > Hello Every1, > > I am looking for VHDL code for a serial port. Small. Fixed Baud rate. > Perhaps only output, don't know that for sure yet. I look at XAPP699 > and started to think that the real code isn't really there, just an IP core > with various wrappers and test benches. Not sure about this. > > Could anybody point the way here? > > Much obliged, > > Brad > > b r a d @ a i v i s i o n . c o m > >Article: 73135
mack wrote:
> Hi,
> When the current AHB slave is busy (hready low) servicing the
> Master,but if the master drives IDLE transfer in the next cycle , then
> according to the protocol slave should give a zero wait state OKAY
> response,but by seeing the hready high for this IDLE response ,master
> will drive it's address and data.Later the slave will drive hready for
> the pending(previous transfer) service.This is malfuntion the current
> transfer...so it is alwayas nessacary to give a zero wait state OKAY
> response for an IDLE transfer??
>
> Regards,
> M.M.Kumar
Hi there,
A few things you need to know:
- An AHB slave don't have to worry what is on HTRANS when HREADY is low
- An AHB master should not change HTRANS, HADDR, HWRITE, etc when HREADY
is low (except when it detected error/retry/split responses).
So for the following waveform is perfectly fine:
T0 T1 T2 T3 T4 T5
_______ _____________________________ ______
HADDR ___A___X___B_________________________X______
_______ _____________________________ ______
HTRANS ___2___X___IDLE______________________X______
_______ _______ _____
HREADY \_____________________/ \/ \
_______ ______ ______
HRDATA/ _______XXXXXXXXXXXXXXXXXXXXXXXX__A___X______X
HWDATA
_______ _____________________________ ______
HRESP ___2___X___OKAY______________________X_OKAY_X
In T0, AHB master issue transfer (note that HREADY is high)
In T1, AHB slave start doing the work (putting HREADY to low)
In T2 and T3, despite HTRANS is IDLE in previous cycle, AHB slaves
can ignore it because HREADY is low.
In T4, AHB slave set HREADY to high, so all AHB slave will have to
check what is on HTRANS, HADDR (also HSEL,HWRITE etc).
In T5, AHB slave output a zero wait state OKAY response for the IDLE in T4.
Hope this answered your question. In addition, question about AHB might
be better be posted on comp.sys.arm newsgroup. (I know, you might not be
using ARM stuffs but I guess more people on that newsgroup can answer
questions on AMBA stuffs).
Regards,
Joe
Article: 73136Yes, that's quite helpful.Article: 73137
Hello everyone: I am design engineer and in the process of evaluating the Xilinx RocketPHY Development Kit (HWK-RPHY-DVLP) http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HWK-RPHY-DVLP&iLanguageID=1 If anyone has had the opportunity to evaluate this board, can you please give me some feedback on the designs implemented and the problems faced. Thanks for the help. FPGAgeekArticle: 73138
We are using the trial version of the OPB Uart 16550 in one of our designs. We are running this at 19200,8,N,1, no flow control. We are using Hyperterminal- and we are able to access the UART ok for generic stuff. Print/scan. We then run a test where we send a bunch of checksum frames (Srecords) to the UART and check them on the PPC. This is done via Hyperterm- send text file. The program makes it thru a couple of hundred of these checksumed Srecords and then reports an error. Seems a piece of one of the Srecords gets lost. We then try the same test with the OPB UART lite and it works flawlessly. All the records are reported correctly. We then tried the same test with another terminal program- Tera Term- and the problems go away for the 550. We are able to send the text file to both the Uart Lite and Uart 550 with no problems. Has anyone seen anything similar to this? It seems the 550 and Hyperterminal do not jive well together. Very odd. We want to buy this core because our OS comes with a 16550 driver- and do not want to write our own.Article: 73139
senthil wrote:
> If the LED is NOT green on your 4 then you have not
>
>>powered it correctly.
>>
>
>
> Hi ..
> I plugged the cable correctly. . the led also blown ie., power came up
> from the usb port..
I suppose you mean parallel port? If not - that's your problem :-)
> all things i made perfectly. but i didn't detect
> the fpga..
What does "the led also blown" mean?
>
> give some suggestion..
Is you BIOS setting for your parallel port set to "ECP"?
>
> Regards
> Senthil.R
--
You've *read the email* - now *buy the book*
Article: 73140Hi! A Xilinx representative came today to the company where I work and he had a short but very informative Virtex4 presentation. What I find very useful is that Xilinx finally put a FIFO control logic on BRAMs and significantly increase their performance. Feature to cascade FIFOs will also be very useful for me. I was also hoping to see a 256 deep and 64bit wide BRAMs, but I guess we'll have to wait for that feature for a while? Several times in the past I bumped into the 8 global clocks limitation on Virtex II. That's why I was very exited to hear that I can use up to 32 global clocks, but after reading the Virtex 4 User's guide (page 21) my excitement cooled down a bit. There is a statement: "However, only eight different clocks can be driven in a single clock region. A clock region is a branch of the clock tree consisting of eight CLB rows up and eight CLB rows down. A clock region only spans halfway across the device." If I understand this correctly, there is still a limitation of 8 global clocks per device, that means max. of 8 different and completely unrelated clocks can be used in all regions of the chip? Please, tell me I'm wrong? ;) While further reading documentation, I found there are several new variable phase-shifting modes available. What's got me worried (about my last Virtex-II design) is the following sentence: "Using the variable-positive and variable-center modes the phase can be dynamically and repetitively moved forward and backwards by 1/256 of the clock period.". In my last Virtex-II design I used 2 variable phase shifted clocks and I'm adjusting the phase dynamically all the time. So far the design is working, but can I expect for example that after one million adjustments (for the sake of simplicity let's say each adjustment increases the phase for 100 steps and then decreases the phase for the same amount of steps) the clock phase will still be 0. I know there are many parameters that can have influence on the stability of phase adjusted clock, but have you measured how repetitively accurate is fine phase adjustment in Virtex-II compared to Virtex-4? I believe most of the new features will be very useful, just bring us the productions chips (not ES) as soon as possible, so we won't have to wait too long as it was the case with Virtex-II. I will probably come up with some new questions tomorrow, because I first have to go over the docs/app notes I downloaded today... Regards, Igor Bizjak "Austin Lesea" <austin@xilinx.com> wrote in message news:ci4p3r$imf1@cliff.xsj.xilinx.com... > All, > > As Peter would say, the teasing is over: V4 is ALIVE. > > http://www.xilinx.com for all of the details. > > Now I can finally talk about it. > > AustinArticle: 73141
Victor Schutte wrote: >Adding 800ns is quite heavy, possibly done with a counter 800ns/ 20ns period >after which the signal is asserted. The same can be done for 80ns (only 4 >periods). > >The compilers are usually intelligent when it comes to optimizing. You add >more time wasting gates and it removes it to increase speed. The one option >is to route a signal to a pin and back through another but that is usually >ineffective and ugly, and ony adds a few ns to the signal. > > I used a version of this in a CPLD application where there was no continuous frequency clock. I put a 5.1 K resistor between an output pin and an input pin, using the parasitic capacitance of the input pin as the C for the RC delay. This worked quite well to clock a counter after the removal of a bus strobe signal. I doubt you could make this work reliably for 800 ns, but 80 ns might be doable. For 800 ns, assuming you don't have enough CLBs for the requisite counter, you would need an external one shot or counter. > > JonArticle: 73142
IgI, See below, Austin IgI wrote: > Hi! > > A Xilinx representative came today to the company where I work and he had a > short but very informative Virtex4 presentation. What I find very useful is > that Xilinx finally put a FIFO control logic on BRAMs and significantly > increase their performance. Feature to cascade FIFOs will also be very > useful for me. I was also hoping to see a 256 deep and 64bit wide BRAMs, but > I guess we'll have to wait for that feature for a while? Yup. Not his time. Aside, do we have enough BRAM? > > Several times in the past I bumped into the 8 global clocks limitation on > Virtex II. That's why I was very exited to hear that I can use up to 32 > global clocks, but after reading the Virtex 4 User's guide (page 21) my > excitement cooled down a bit. There is a statement: "However, only eight > different clocks can be driven in a single clock region. A clock region is a > branch of the clock tree consisting of eight CLB rows up and eight CLB rows > down. A clock region only spans halfway across the device." > If I understand this correctly, there is still a limitation of 8 global > clocks per device, that means max. of 8 different and completely unrelated > clocks can be used in all regions of the chip? Please, tell me I'm wrong? ;) Sorry, you are correct. Eight clocks per region. I don't understand why folks want so many different clocks-- ever heard of synchronous design? Regions are smaller than they used to be (smaller than quadrants) so having different clocks for different regions still allows a real nightmare of asynchonous clock designs. That combined with the additional local clocks for IOs gives you even more opportunities to cross asynchronous clock domains......... > > While further reading documentation, I found there are several new variable > phase-shifting modes available. What's got me worried (about my last > Virtex-II design) is the following sentence: "Using the variable-positive > and variable-center modes the phase can be dynamically and repetitively > moved forward and backwards by 1/256 of the clock period.". In my last > Virtex-II design I used 2 variable phase shifted clocks and I'm adjusting > the phase dynamically all the time. So far the design is working, but can I > expect for example that after one million adjustments (for the sake of > simplicity let's say each adjustment increases the phase for 100 steps and > then decreases the phase for the same amount of steps) the clock phase will > still be 0. I know there are many parameters that can have influence on the > stability of phase adjusted clock, but have you measured how repetitively > accurate is fine phase adjustment in Virtex-II compared to Virtex-4? Yes we have. V4 has even finer steps than V2P, and comes back to the same place +/- 12 ps. With V2p it was +/- 25 ps. Absolute. You worry about the oddest things......the DCM is all digital and a state machine, so it has no choice when it comes to where it should be.... One million or one trillion clocks, a flip flop doesn't care, and neither does the DCM. > > I believe most of the new features will be very useful, just bring us the > productions chips (not ES) as soon as possible, so we won't have to wait too > long as it was the case with Virtex-II. Virtex II went cleanly into production with no delays. It was Virtex II Pro, and the issue of low K dielectrics that delayed that product family. We don't care to use low-K anymore unless it gets production qualified on someone else's dime. > > I will probably come up with some new questions tomorrow, because I first > have to go over the docs/app notes I downloaded today... Happy reading! > > Regards, > Igor Bizjak > > > "Austin Lesea" <austin@xilinx.com> wrote in message > news:ci4p3r$imf1@cliff.xsj.xilinx.com... > >>All, >> >>As Peter would say, the teasing is over: V4 is ALIVE. >> >>http://www.xilinx.com for all of the details. >> >>Now I can finally talk about it. >> >>Austin > > >Article: 73143
Hi,
I am designing a simple ROM in VHDL and following is the code for
it.Xilinx ISE 6.2i doesn't seem to have any issues synthesizing the
design to a Virtex 2 chip(xc2v4000) or translating/mapping/routing the
design(Implementation process).
When I use the test bench created by HDL bencher to see the results,
in Modelsim, a behavioral simulation shows be proper results but a
post translate simulation or anything beyond that like a Post Map or a
Post place and route simulation show a U on all output pins and
Modelsim gives me a number of warnings about "Unbound components"
shown below..
Im stuck at this design phase and would appreciate any help from the
VHDL gurus out there...Heres the code:-
-----------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
-- Uncomment the following lines to use the declarations that are
-- provided for instantiating Xilinx primitive components.
--library UNISIM;
--use UNISIM.VComponents.all;
entity inrom is
Port ( en : in std_logic;
clk : in std_logic;
dout : out std_logic_vector( 15 downto 0);
valid : out std_logic; --valid data is present on output when 1
reset : in std_logic
);
end inrom;
architecture rtl of inrom is
type array_rom is array (15 downto 0) of std_logic_vector( 15 downto
0);
signal myarray : array_rom;
signal valid_sig:std_logic;
signal dout_sig : std_logic_vector(15 downto 0);
signal clk2: std_logic;
begin
myarray(0) <= x"0000";
myarray(1) <= x"0000";
myarray(2) <= x"0000";
myarray(3) <= x"003C";
myarray(4) <= x"0000";
myarray(5) <= x"0000";
myarray(6) <= x"0064";
myarray(7) <= x"0000";
myarray(8) <= x"0000";
myarray(9) <= x"000A";
myarray(10) <= x"0000";
myarray(11) <= x"0000";
myarray(12) <= x"003C";
myarray(13) <= x"0000";
myarray(14) <= x"0000";
myarray(15) <= x"0064";
process( reset,clk)
variable romvar:natural range 0 to 15;
begin
if reset = '1' then
dout_sig <= (others=>'0');
valid_sig <='0';
romvar :=0;
elsif (clk'event and clk='1') then
if en='1' then
dout_sig <= myarray (romvar);
valid_sig<='1';
romvar :=romvar + 1;
else
dout_sig <= myarray (romvar);
valid_sig<='0';
end if;
end if;
end process;
dout <= dout_sig;
valid <=valid_sig;
end rtl;
-------------------------------------------------------------------------
Warnings given by Modelsim:
do inromtbw.ndo
# ** Warning: (vlib-34) Library already exists at "work".
###### inrom_translate.vhd(443): );
# WARNING[1]: inrom_translate.vhd(443): No default binding for
component: "x_mux2". (No entity named "x_mux2" was found)
###### inrom_translate.vhd(455): );
# WARNING[1]: inrom_translate.vhd(455): No default binding for
component: "x_ff". (No entity named "x_ff" was found)
###### inrom_translate.vhd(468): );
# WARNING[1]: inrom_translate.vhd(468): No default binding for
component: "x_xor2". (No entity named "x_xor2" was found)
###### inrom_translate.vhd(472): );
# WARNING[1]: inrom_translate.vhd(472): No default binding for
component: "x_zero". (No entity named "x_zero" was found)
###### inrom_translate.vhd(476): );
# WARNING[1]: inrom_translate.vhd(476): No default binding for
component: "x_one". (No entity named "x_one" was found)
###### inrom_translate.vhd(714): );
# WARNING[1]: inrom_translate.vhd(714): No default binding for
component: "x_lut2". (No entity named "x_lut2" was found)
###### inrom_translate.vhd(2994): );
# WARNING[1]: inrom_translate.vhd(2994): No default binding for
component: "x_lut3". (No entity named "x_lut3" was found)
###### inrom_translate.vhd(3128): );
# WARNING[1]: inrom_translate.vhd(3128): No default binding for
component: "x_lut4". (No entity named "x_lut4" was found)
###### inrom_translate.vhd(3203): );
# WARNING[1]: inrom_translate.vhd(3203): No default binding for
component: "x_or2". (No entity named "x_or2" was found)
###### inrom_translate.vhd(3341): );
# WARNING[1]: inrom_translate.vhd(3341): No default binding for
component: "x_tri". (No entity named "x_tri" was found)
###### inrom_translate.vhd(3450): );
# WARNING[1]: inrom_translate.vhd(3450): No default binding for
component: "x_inv". (No entity named "x_inv" was found)
###### inrom_translate.vhd(3533): port map (O => GSR);
# WARNING[1]: inrom_translate.vhd(3533): No default binding for
component: "x_roc". (No entity named "x_roc" was found)
###### inrom_translate.vhd(3535): port map (O => GTS);
# WARNING[1]: inrom_translate.vhd(3535): No default binding for
component: "x_toc". (No entity named "x_toc" was found)
# vsim -lib work -t 1ps inromtbw
# Loading C:/Modeltech_5.7g/win32/../std.standard
# Loading C:/Modeltech_5.7g/win32/../ieee.std_logic_1164(body)
# Loading C:/Modeltech_5.7g/win32/../ieee.std_logic_arith(body)
# Loading C:/Modeltech_5.7g/win32/../std.textio(body)
# Loading C:/Modeltech_5.7g/win32/../ieee.std_logic_textio(body)
# Loading C:/Modeltech_5.7g/win32/../vital2000.vital_timing(body)
# Loading C:\Xilinx6\vhdl\mti_se\simprim.vcomponents
# Loading C:/Modeltech_5.7g/win32/../vital2000.vital_primitives(body)
# Loading C:\Xilinx6\vhdl\mti_se\simprim.vpackage(body)
# Loading work.inromtbw(testbench_arch)
# Loading work.inrom(structure)
# ** Warning: (vsim-3473) Component 'romvar_madd_n0000_inst_cy_5_0' is
not bound.
# Time: 0 ps Iteration: 0 Region: /inromtbw/uut File:
inrom_translate.vhd
# ** Warning: (vsim-3473) Component 'valid_sig_1' is not bound.
# Time: 0 ps Iteration: 0 Region: /inromtbw/uut File:
inrom_translate.vhd
# ** Warning: (vsim-3473) Component 'mmux_n0001_inst_mux_f5_130' is
not bound.
I can not use a Core generated ROM for this design due to some
restrictions I have in my other codes..Sorry for a rather long mail
and thanks in advance for any help!!
Article: 73144Once upon a time I saw a number that told me what percentage of my project was unconstrained. I can't seem to get TRCE (Xilinx ISE) to show me that number again. Can someone point me in the right direction? -- Prepend a 'b' to email me. Thanks.Article: 73145
>Sorry, you are correct. Eight clocks per region. I don't understand >why folks want so many different clocks-- ever heard of synchronous >design? Regions are smaller than they used to be (smaller than >quadrants) so having different clocks for different regions still allows >a real nightmare of asynchonous clock designs. > >That combined with the additional local clocks for IOs gives you even >more opportunities to cross asynchronous clock domains......... How good is current software at identifying signals/paths that cross clock domains? It seems as though there should be some mechanism where you can tag a signal as asynchronous and/or tag the first FF as a synchronizer and specify how much extra time you need. Anything that crosses clock domains without being tagged should get flagged as an error. (Or something like that.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 73146
> I think it's better that I answer that. > MicroBlaze will run about 185 MHz in speedgrade -12. > With the new architecture Virtex4, I will need to create a different > aspect ratio on the RPM block since this architecture is smaller and higher. > VII and V2Pro was more rectangular in the shape. > With the new floorplan I achieves 165 MHz in -11 and this will give us > around 185 MHz in -12. So that's only 10% faster that a vIIp then? Don't get me wrong, a 185 MHz CPU is pretty fantasic, it just doesn't seem that the v4 is giving it that much of a kick. Cheers, JonBArticle: 73147
"Austin Lesea" <austin@xilinx.com> wrote in message news:ci7nuk$imf5@cliff.xsj.xilinx.com... > IgI, > > > Several times in the past I bumped into the 8 global clocks limitation on > > Virtex II. That's why I was very exited to hear that I can use up to 32 > > global clocks, but after reading the Virtex 4 User's guide (page 21) my > > excitement cooled down a bit. There is a statement: "However, only eight > > different clocks can be driven in a single clock region. A clock region is a > > branch of the clock tree consisting of eight CLB rows up and eight CLB rows > > down. A clock region only spans halfway across the device." > > If I understand this correctly, there is still a limitation of 8 global > > clocks per device, that means max. of 8 different and completely unrelated > > clocks can be used in all regions of the chip? Please, tell me I'm wrong? ;) > > Sorry, you are correct. Eight clocks per region. I don't understand > why folks want so many different clocks-- ever heard of synchronous > design? Regions are smaller than they used to be (smaller than > quadrants) so having different clocks for different regions still allows > a real nightmare of asynchonous clock designs. > > That combined with the additional local clocks for IOs gives you even > more opportunities to cross asynchronous clock domains......... > Indeed, when I saw that there are 32 global clocks in V4, my heart sank. Unlike Igor, I'm sick and tired of fixing shoddy designs that are the result of inexperienced designers throwing as many clocks as possible at their designs. Go synchronous, young man! Cheers, Syms.Article: 73148
MS wrote: > Has anyone seen anything similar to this? It seems the 550 and > Hyperterminal do not jive well together. Very odd. We want to buy > this core because our OS comes with a 16550 driver- and do not want to > write our own. IMHO Hyperterm is an absolute piece of garbage! I've had no end of troubles over the years with it on various different applications, usually involving flow control but also dropped chars etc. For years, the 'standard' test I used for serial comms was the DOS-based Telix. These days I find Tera Term Pro does the job quite well. More recently I've used PuTTY, but haven't used it extensively. If I were you, I'd try 1 or 2 *other* terminal programs (is a DOS-based one pratical just for the sake of piece-of-mind testing, or even Minicom on Linux?) and if none of those have problems, curse Micro$oft and vow never to touch Hyperterm again! Regards, -- | Mark McDougall | "Electrical Engineers do it | <http://to be announced> | with less resistance!"Article: 73149
Hi Brendon, Thanks Brendon for the response. Yes, I am using 6.2.03i of xpower. Can I get web updates? Also, do we need to get update for xpower alone or we have to get for complete ISE. I also saw on xilinx web site that ISE 6.3i is released too on 9/13. Pls clarify what all i need to upgrade if I have ISE 6.2 and xpower 6.2.03i -- Mukesh Brendan Cullen <bcullen@xilinx.com> wrote in message news:<41404E30.47F20BF8@xilinx.com>... > > This does indeed look similar to another problem which we've been working > on. We have a fix for that problem (the one we've been working on) and > the fix will be available in the next service pack - 6.3.01i - which > should be available to you next week. However, you might be experiencing > a diferent symptiom. One option would be for you to zip up the NCD & VCD > file and send them to us ? Or are they huge ? The other option is for > you to try the service pack next week. Note - in order for you to use > 6.3.01i you'll need to have the underlying 6.3i. (From your other e-mail > to the newsgroup it appears you are using 6.2.03i.) > > Brendan
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