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
Noddy <g9731642@campus.ru.ac.za> wrote: > How exactly are Xilinx's Foundation timing scores calculated? Write now I > have just been comparing different incarnations of my design, and so things > are relative to each other. But what is a good timing score, say for a 100 > 000 gate design? Zero would be perfect. (Or have I missed something obvious here?) Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 42926
In article <VMQB8.339$GLp1.155@news01.bloor.is.net.cable.rogers.com>,
Roger King <roger@king.com> writes
>Can one build an OP-AMP in an FPGA?
A digital op-amp, now there's a thing. In a word, no.
Some analog functions (oscillators, comparators) may be available
either on special-function I/O pads, or by abusing standard I/O
pads in various ways. Trawl your chosen manufacturers' appnotes.
However, there are some programmable analog array devices around.
Optimagic lists (and has links to) three suppliers at
http://www.optimagic.com/companies.html#Analog
Lattice Semi have the ispPAC family which they acquired from a
small, now defunct startup whose name I've forgotten. It's a
configurable bag of gain blocks, filter blocks and suchlike
useful things.
Zetex have the TRAC range, marketed by their Fast Analog Solutions
division; it's intended for analog signal processing or analog
computing tasks, and has some very neat features but is less likely
to be useful for general-purpose applications.
Anadigm's FPAA devices look suspiciously like the programmable
analog parts that Motorola launched a few years ago and then
withdrew in unseemly haste, but I'll need to go back to my
databook archive to check that suspicion!
--
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223 Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573 Web: http://www.doulos.com
**********************************
** Developing design know-how **
**********************************
This e-mail and any attachments are confidential and Doulos Ltd. reserves
all rights of privilege in respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from your system, any use, disclosure, or copying of this document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 42927Roger King ha scritto nel messaggio ... >Can one build an OP-AMP in an FPGA? No. FPGA are strictly digital devices. But if you are searching some programmable analog device, give a look to Lattice ispPAC www.latticesemi.com LuigiArticle: 42928
"Austin Lesea" <austin.lesea@xilinx.com> schrieb im Newsbeitrag news:3CD6E522.8BA1BB2C@xilinx.com... > Nahum, > > The jitter calculator program yields the following worst case results: > > 125 X 2 = 0.67 ns P-P, or 16.8% UI > > 50 X 5 = .61 ns P-P, or 15.2% UI ?? Isnt this strange? From my understanding, a DCM is a upgraded DLL. Right? So why does it produce such big jitter, when a DLL is specified to +/-200ps max.? And why has the 50x5 mode lower jitter than the 125x2 ?? -- MfG FalkArticle: 42929
Hi Ryan, brief answer: No, you can't. The partial reconfiguration flow is a subset of the Modular Design flow. For each of the reconfiguration-modules you need to run the implementation on the single module. After you have the implementation data for each module you'll need to stitch the files together and create the initial and partial bitstreams. The latter one can be done either by comparing the bitstreams which each other and creating small bit-streams with only the differences or you can create the re-configuration bitstream from the floorplanning-information. From the timing point of view you can save yourself quite some time for the re-configuration of the device. I did a test once with a Virtex-E 600 and a MultiLINX Cable on the serial port (slowest BAUD-rate). The complete configuration took about 1.5 minutes. Re-configuration with a small bit-stream took about 8 seconds. As you can see there can be quite a difference in configuration time. (BTW: Normal Configuration via MultiLINX and USB took about 13 seconds, re-configuration was only a glimpse.) but as you can surely imagine, the time for re-configuration is very dependend on the changes you are doing. If you are only doing minor changes re-configuration will be quicker than if you'd do major changes. MartinArticle: 42930
> Noddy <g9731642@campus.ru.ac.za> wrote: > > How exactly are Xilinx's Foundation timing scores calculated? Write now I > > have just been comparing different incarnations of my design, and so things > > are relative to each other. But what is a good timing score, say for a 100 > > 000 gate design? > > Zero would be perfect. (Or have I missed something obvious here?) Zero (as far as I know) means you've met all your timing constraints, which is the optimum. However, if you have multiple constraints and non-zero scores, the best timing score may not be your best result. If you set all your constraints to be 10% above required to give you head room, you might get one run where all the constraints miss by a bit but are still acceptable, and another run where one constraint is below your minimum required value but all the others are met. Chances are the run where only one constraint failed will have a better timing score, but it's not the one you want to implement. There's no substitute for checking the actual timing tables in the end. I wrote a Tcl script to run after doing a multi-pass p&r that grabs all the timing tables out of the report files and puts them in a single text file so they're easier to scan. As for the original question, there's no set answer to what a good timing score is other than as close to 0 as possible. The values you get will depend on how tough you set your constraints. In one design we're working on we put an overly tight timing constraint on one path to make it better meet our desired timing; this resulted in our timing scores being lower since it could never meet the constraint, but the actual speed improved. Pete -- Peter Young Hardware Designer AMIRIX Systems - Halifax, N.S. http://www.amirix.comArticle: 42931
Falk, Great mysteries of life I supose. The DCM 'free runs' inbetween phase updates. Phase updates occur every three concurrences. A concurrence is defined as when the clock in and the clock out both have a rising edge at the same time (ie every 5 input clocks for a 7/5 M/D). When that concurrence time happens, the phase is re-synchronized to match exactly. This either lengthens or shortens that one clock out period. The peak to peak jitter is dominated by the resyncing error at the concurrence. Some numbers are better than others (Douglas Adams knew all about this strange but true fact, do you recall Bistromathics?). We measured the worst case jitter for every M and D, and a wide range of input clocks. This was done over process corners, and over voltage and temperature. The result was complex enough that we wrote a program to best fit the results into a predictor. Good news is that the jitter behaves in a linear fashion, and is predicted by an ax+b=y fit. Austin Falk Brunner wrote: > "Austin Lesea" <austin.lesea@xilinx.com> schrieb im Newsbeitrag > news:3CD6E522.8BA1BB2C@xilinx.com... > > Nahum, > > > > The jitter calculator program yields the following worst case results: > > > > 125 X 2 = 0.67 ns P-P, or 16.8% UI > > > > 50 X 5 = .61 ns P-P, or 15.2% UI > > ?? Isnt this strange? From my understanding, a DCM is a upgraded DLL. Right? > So why does it produce such big jitter, when a DLL is specified to +/-200ps > max.? > And why has the 50x5 mode lower jitter than the 125x2 ?? > > -- > MfG > FalkArticle: 42932
This is a multi-part message in MIME format. --------------84ED56E781F9A3076B9770B4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jay, Have you tried loading the design without the *.pcf file. The memory limit *shouldn't* be hit unless you have a very large number of constraints to annotate. Dave Jay wrote: > It appears that on a fully utilized XC2V6000, there is no solution to > be able to run the FPGA Editor. The program hits the 2GB memory limit > and quits. How did Xilinx test there code? I know that the memory > limit is imposed by Microsoft, and it is what it is, and there is no > changing that any time soon. So why can't Xilinx recode to use the > available memory space more efficiently or store data on the HD so at > least I can run (albeit more slowly). > > And another thing, guess I can accept waiting 30 minutes to load a > database into a tool, but it seems crazy to have to wait another 30 > minutes to exit without even saving just to get my memory back.Article: 42933
The guys at Xilinx can correct/clarify this, but I have noticed (perhaps
have read) that the timing score is the sum, in picoseconds, of "total
negative slack;" i.e., add up the values for all of the paths that
didn't meet the constraints, and there you have it.
The other replies did a reasonable justification to what it means in a
more qualitative sense (i.e., what should I do with this number.)
Of course, the number out is no better than the constraints in.
Jason T. Wright
Noddy wrote:
>
> Hi,
>
> How exactly are Xilinx's Foundation timing scores calculated? Write now I
> have just been comparing different incarnations of my design, and so things
> are relative to each other. But what is a good timing score, say for a 100
> 000 gate design?
>
> Thanks
> adrian
--
Jason T. Wright
The opinions I express are my own ...
unless otherwise indicated!
Article: 42934"Austin Lesea" <austin.lesea@xilinx.com> schrieb im Newsbeitrag news:3CD8199D.EAB95421@xilinx.com... > Falk, > > Great mysteries of life I supose. > > The DCM 'free runs' inbetween phase updates. Phase updates occur every three > concurrences. A concurrence is defined as when the clock in and the clock out > both have a rising edge at the same time (ie every 5 input clocks for a 7/5 > M/D). When that concurrence time happens, the phase is re-synchronized to match > exactly. This either lengthens or shortens that one clock out period. The peak > to peak jitter is dominated by the resyncing error at the concurrence. Hmm, but shouldnt then the 125x2 mode be better? Since there is an update every 2nd input clock and the probalibity of the free running DCM drifting away is less. > Some numbers are better than others (Douglas Adams knew all about this strange > but true fact, do you recall Bistromathics?). I know ;-) -- MfG FalkArticle: 42935
Falk, Again, what can I say? The common wisdom is neither common, nor wise. There are many puzzlements in the data, but we think we understand them all. I do not want to get into the subtle details, as that would be discussing the actual implementation of the DFS, which until the patent is granted, is considered proprietary. Austin Falk Brunner wrote: > "Austin Lesea" <austin.lesea@xilinx.com> schrieb im Newsbeitrag > news:3CD8199D.EAB95421@xilinx.com... > > Falk, > > > > Great mysteries of life I supose. > > > > The DCM 'free runs' inbetween phase updates. Phase updates occur every > three > > concurrences. A concurrence is defined as when the clock in and the clock > out > > both have a rising edge at the same time (ie every 5 input clocks for a > 7/5 > > M/D). When that concurrence time happens, the phase is re-synchronized to > match > > exactly. This either lengthens or shortens that one clock out period. > The peak > > to peak jitter is dominated by the resyncing error at the concurrence. > > Hmm, but shouldnt then the 125x2 mode be better? Since there is an update > every 2nd input clock and the probalibity of the free running DCM drifting > away is less. > > > Some numbers are better than others (Douglas Adams knew all about this > strange > > but true fact, do you recall Bistromathics?). > > I know ;-) > > -- > MfG > FalkArticle: 42936
I'm trying to figure out where to locate the RocketIO swift models to simulate RocketIO using Synopsys VCS or Cadence Verilog under SPARC Solaris 8. Answers Database #14019 mentiones the Virtex-II Pro Developers kit (V2PRO). However, the ISE 4.2iSP2 appears to have a GT_SWIFT installation under verilog/smartmodel/sol/wrappers/vcs/GT_SWIFT.swift.v The problem is that I can't find any instructions on how to use it, i.e. which object file can I link into my simulator. AD#14019 specifies a library file in the V2PRO under verilog/smartmodel/sol/installed/lib/sun4Solaris.lib, but this file does not seem to exist under ISE 4.2iSP2. 1) Is the Virtex-II Pro Developers kit required to simulate the RocketIO interfaces? 2) If not, which library/object file supplied with ISE 4.2iSP2 do I use? 3) Further there is a x86_linux directory containing som Linux X86 binaries under verilog/smartmodel/sol/image. Is, or will Linux X86 swift models be supplied so I can run my simulations on Synopsys VCS or Cadence Verilog under Linux X86? BTW. I'm familiar with swift models since I have used VMC to generate swift models of my own ASIC designs. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 42937
I am since a long time a programmer I find this product very interesting. I can execute interpreted code directly on my PC microprocessor http://www.hyperpanel.com/boot_direct.php3?ID=13550507Article: 42938
Alex -
Here is some advice from an ex-Altera employee of 10 years.(requested
disclosure)
I took a quick browse of your website and realize that you are a small
company. It is unclear the extent of your staffing and engineering
capabilities
but non the less it appears that you do not have the inhouse expertise
for the
customization and chip development. I base this speculation purely on
the news releases of your website and open positions.
Anyway - being that you currently lack the true in house expertise and
that you
are a startup here below are my suggestions. HOwever here are some of
the
facts that I took into consideration for these suggestions...
a. you are a startup and no matter how well funded - cash is king
b. not every great idea succeeds (lots of competition for wireless
broadband)
c. volumes are not yet truely defined unless you have minimums based on
a contract with cusotmer
d. luckily PCI is a fairly mature spec and many people have experience
recommendations:
1. inficon should create the high level specification for what needs to
be developed for the whole chip or chip-set
2. implement a stagged solution that will reduce risk and ultimately
maximize profit
3. for ultimate risk reduction use FPGA technology for prototypes (hash
out any bugs/spec changes) into initial-mid production
4. rather than spin it yourself, obtain a Fixed Bid from an FPGA
consultant partner program
You will be able to find a consulting firm (my info below) with PCI
experience with IP from the vendor
5. You should consider the initial project/bid from the consulting firm
to just include development of the low level spec such that
risk is further reduced and better fix-bid can be presented for full
implementation
6. involve your local FPGA vendor's sales teams
7. once the high level spec and other details have been worked through,
estimate the size of the
actual FPGA device you will need and its embedded resources (ask
consultant)
8. ask your FPGA vendor to provide you quotes for different volume
levels - specify the time fram for each volume level too
9. ask your FPGA vendor what other suggestions they could make to
further reduce solution cost - example Altera Hard Copy
(non-programmable reduced cost) or
or Xilinx Easy Path (reduced cost but still needs configuration)
10. ask about IP source code - I know Altera will provide a quote if you
do need to ultimately go asic
This approach should reduce Inficon's risk yet provide an optimum manner
to implement your design needs,
reduce both technical and cost risks, minimize direct personnel
expenses, and maximize ultimate profits.
Many people jump to the conclusion that an asic would be best here since
you mentioned Millions of units.
However, being that it appears that you have unproven technology, your
specs may change or evolve which
is much better suited toward FPGAs especially since time to market will
likely be important too.
I likely forgot to mention something but it is "after hours" :-)
Below is my contact information should you want to discuss further...
Best of Luck,
Guy Schlacter
g.schlact@-nospamm-attbi.com
http://absoluteconsulting.home.attbi.com
"Alex Rast" <arast@inficom.com> wrote in message
news:llDB8.174$vz5.79857@news.uswest.net
> OK, I apologize in advance. What I'm asking is virtually guaranteed to start a
> firestorm. I realize that this is a topic about which people will have both
> strong biases and vested interests. So, before starting, I beg everybody:
> Please, let's not turn this question into a battle of opposing polemics.
>
> I'm involved in a commercial project with projected volumes into the 100's of
> thousands if not millions per month. We've got a PCI card, and we've decided
> to implement the PCI interface in an FPGA, along with multiple other
> functions.
>
> What I would like is opinions as to the best PCI core developers. Let's say
> for the moment that the FPGA brand isn't particularly important, or is open to
> change. I don't care if the core in question comes from the FPGA manufacturer,
> a third-party vendor or consultant, or a freeware download. We'd like people's
> real-world experiences as to which cores work reliably, efficiently, at high
> speed, bug-free, and in full compliance with the spec.
>
> Also, are there any cores where the source code isn't supplied and/or isn't
> modifiable? If so, I'd like to get some perspective on the quality/reliability
> of such "hard-coded" cores as opposed to "soft" cores which the user can
> modify as needed.
>
> I'd also like to know whether the cores that you recommend are 33 MHz, 66 MHz,
> what version of PCI they're compliant with, and whether they're target,
> master, or bridge. If the developer supplies various different types, and if
> you have experience, give me your opinions on each version if possible, so I
> can see how the relative merits stack up for each implementation.
>
> Alex Rast
> arast@inficom.com
> arast@qwest.net
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Article: 42939Semiconductor Track: EDA and Beyond: Funding and Industry Trends To Register: http://www.mitcnc.org/Events_Single.asp?eventID=593 Date: 05/09/2002 Thu Time: 7:00pm Venue: Applied Materials, Bower s Café Location: 3100 Bowers Ave, Santa Clara, CA Cost: $20.00 Contact: s.ritterbush@alum.mit.edu Join fellow entrepreneurs and industry professionals for an evening panel event that will offer valuable information and insights directly from successful entrepreneurs representing EDA, Design IP, Design Collaboration, and related areas. Get the inside track on strategic trends and the realities of starting a business in this industry sector. Doors open at 630pm for walk-in registration and networking session; networking session to continue after the panel discussion. Panelists: Ajoy Bose - CEO, Atrenta Dr. Bose has over 25 years experience in engineering and management. Prior to establishing Atrenta, Dr. Bose was founder and president of Interra Inc, and Software & Technologies. At AT&T Bell Labs, he rose to the position of department head before leaving for Cadence Design Systems, where he was Vice President of Engineering. Dr. Bose received his Bachelors degree from the Indian Institute of Technology and his PhD from the University of Texas at Austin Thomas Heydler CEO, Barcelona Design Mr. Heydler joined Barcelona Design in September 2001 from InterPro Business Solutions Inc., where he was president and CEO, responsible for repositioning and streamlining the business to become a leader in Procurement Management Services. Mr. Heydler has more than 17 years of experience in the area of general management, sales, marketing, strategic planning and international operations. Mr. Heydler holds a Master in Computer Science from the Technical University Munich. Mike Shuh - General Partner, Foundation Capital Before joining Foundation Capital in 1998, Mr. Shuh was CEO, co-founder, and chairman of the board of Intrinsa Corporation, a software applications company that was acquired by Microsoft. He was the vice president of sales at Clarify, Cadence Design Systems and Computervision prior to co-founding Intrinsa; he currently serves on the boards of Barcelona Design, Netflix, Responsys and Vivecon. Mr. Shuh received a BSEE from the University of Maryland. Robert Smith - Vice President, Product Marketing, Magma Design Automation Robert Smith joined Magma in 1998 as vice president, marketing, and presently serves as vice president, product marketing. From 1995 to 1998 Mr. Smith was vice president of marketing and business development at LogicVision. From 1989 to 1995, Mr. Smith held several positions with Synopsys, including director of marketing and director of strategic alliances. Mr. Smith received a bachelor's degree in electrical engineering from the University of California, Davis, and a master's degree in electrical engineering from Stanford University.Article: 42940
Hi folks,
I've developed a simple state machine targetted at an XC4010 FPGA, which
writes values to an external SRAM.
The state machine is simple, and behavioural simulation looks perfect.
The general concept is that a data value gets placed on the inputs, my
design is strobed, it latches the input, asserts the data and address
bus, then strobes the RAM to write the value. After the RAM is strobed,
the address and data bus are un-asserted, and the address pointer
incremented. Then it starts all over again.
I have 8 clock cycles between strobe events, so took a conservative
approach to the design, whereby the RAMs address and data buses are
asserted 1 cycle before the RAM is strobed, and held stable for one
cycle afterwards, to prevent the address or data changing while the RAM
is writing.
As I said, the design does a behavioural sim perfectly, but when I do a
post P&R sim it fails completely, with the outputs all going undefined
very soon after the sim starts. I downloaded the design to the chip
and, unsurprisingly, it failedto work there either!
I am using a 3 process model for the state machine. The first process
registers the state variable, the second process performs the state
transitions, and the 3rd drives the outputs as a function of the current
state.
Following is the VHDL code for my design, I hope it's not too long for
someone to take a look and give me some tips. Another point of note,
when I do the post P&R sim I get the followign warnings, but am unsure
quite how to respond to fix whatever is causing it.
# ** Warning: */X_FF SETUP Low VIOLATION ON I WITH RESPECT TO CLK;
# Expected := 1.3 ns; Observed := 0.525 ns; At : 10.94 ns
# Time: 10940 ps Iteration: 0 Instance:
/testbench/uut/cur_state_reg_2_i_1
Here is th ecode. Thanks in advance for any help.
John
--begin ram_writer.vhd
-- A Simple SRAM output driver. 8 bit data are clocked in and written
to
-- a 32K SRAM attached to the CEB, OEB, WEB, A and D lines
-- Each successive byte is written to the next address, up to 0x7FF
-- WEB, CEB and OEB are all active low RAM control signals
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity ram_writer is
Port ( reset : in std_logic;
clk : in std_logic;
strobe : in std_logic;
d_in : in std_logic_vector(7 downto 0);
en : in std_logic;
ceb : inout std_logic;
oeb : inout std_logic;
web : inout std_logic;
a_out : inout std_logic_vector(14 downto 0);
d_out : inout std_logic_vector(7 downto 0));
end ram_writer;
architecture Behavioral of ram_writer is
signal pointer : integer range 0 to 32767;
signal int_data : std_logic_vector(7 downto 0);
-- an internal signal to enable the outputs (Except ceb)
signal oen : std_logic;
type state_type is (init,ready, latch, write1, write2,
update, wait_strobe_low, finished);
signal cur_state, next_state : state_type;
begin
-- tristate the address and data outputs on the "oen" signal
a_out <= conv_std_logic_vector(pointer,15) when oen='1'
else (others => 'Z');
d_out <= int_data when oen='1'
else (others => 'Z');
-- RAM control signals are active low
-- output enable bit on RAM.
oeb <= '1' when oen='1' else -- disable if we are in control
'Z';
-- doing burst mode transfer, so hold write on, and strobe with chip
select
web <= '0' when oen='1' else
'Z';
-- register the state variable
state_reg:process(reset,clk)
begin
if(reset='1') then
cur_state <= init;
elsif(clk'event and clk='1') then
if(en='1') then
-- normal state progression
cur_state <= next_state;
else
-- hold in init state if en='0'
cur_state <= init;
end if;
end if;
end process;
-- state transition process
state_update:process(cur_state,d_in,strobe)
begin
case cur_state is
when init =>
pointer <= 0;
int_data <= (others => '0');
next_state <= ready;
when ready =>
if(strobe='1') then
-- latch the data off the input
int_data <= D_in;
next_state <= latch;
else
next_state <= ready;
end if;
when latch =>
next_state <= write1;
when write1 =>
next_state <= write2;
when write2 =>
next_state <= update;
when update =>
-- increment the pointer
if pointer<32767 then -- don't wrap past top of RAM
pointer <= pointer+1; -- increment the address for next time
next_state <= wait_strobe_low;
else
next_state <= finished;
end if;
when wait_strobe_low =>
if (strobe='0') then
next_state <= ready;
else
next_state <= wait_strobe_low;
end if;
when finished =>
next_state <= finished;
when others =>
next_state <= init;
end case;
end process;
-- defines the outputs based on the current state
outputs: process(cur_state)
begin
case cur_state is
when init =>
-- disable outputs, don't drive RAM chip select
oen <= '0';
ceb <= 'Z';
when ready =>
-- disable the outputs and don't assert the RAM chip select
oen <= '0';
ceb <= 'Z';
when latch =>
-- assert the outputs but don't drive the chip select yet
oen <= '1';
ceb <= 'Z';
when write1 =>
-- assert outputs and drive chip select
oen <= '1';
ceb <= '0';
when write2 =>
-- unassert chip select
ceb <= 'Z';
when update =>
-- disable the outputs
oen <= '0';
ceb <= 'Z';
when wait_strobe_low =>
oen <= '0';
ceb <= 'Z';
when finished =>
null;
when others =>
null;
end case;
end process;
end Behavioral;
Article: 42941Hi! Am looking for some t6echnical details on FPGA based Cellular Base stations incl BSC & BTS. If some body can help me with few system diagrams of BSS where FPGA had been used , or some actuall block diagrams of BSS from some co. with FPGA on a card or anywhere being used regrads GauravArticle: 42942
John Williams wrote:
>
>
> As I said, the design does a behavioural sim perfectly, but when I do a
> post P&R sim it fails completely, with the outputs all going undefined
> very soon after the sim starts. I downloaded the design to the chip
> and, unsurprisingly, it failedto work there either!
>
I don't use VHDL, so I cannot comment on your code, but I have
seen synthesis tools messing up synthesis, and even recently, I saw a
synthesis tool that somehow got rid of valid FFs (FFs actually being
used. Not dead FFs.) from a design.
The synthesis tool I used here was Xilinx ISE WebPACK 4.2's XST (Xilinx
Synthesis Technology Ver. E.35), and it took me 2 days to figure out a
workaround because since ISE 4.x, XST doesn't generate an EDIF file.
(Instead, an encrypted .NGC file is generated, and I resent that.)
I had to install WebPACK ISE 3.3, and the XST there (Ver. D.27) was also
having the same problem, but at least the older XST generated an EDIF
file, so I was able to see it for myself that valid FFs were indeed
missing from my design.
The problem seems like it is an XST's bug, but eventually I found a
workaround by changing a synthesis option, and the problem disappeared
in both versions of XST.
So, since your design works on a simulator, I will suspect that it is a
synthesis tool bug, and you may want to disable/enable some synthesis
options.
Regards,
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 42943John, You are letting the SRAM controls go hi-Z. Does this controller share access to the SRAM? If it is the only master, then only the data bus should go hi-Z. In any event, only the data bus should be inout, the other ports s/b out. For the signals that go hi-z, does your board level design, and the test-bench include pull-ups? In your state transition process int_D will infer latches. Is this what you want? Since you are defining tri-states, the NULL declaration for the finished state appears dangerous. A common coding style for decoders is to define the default values for outputs ahead of the case statement, and then only define deviations from the defaults in the case statement. This: 1. Ensures default behavior. 2. Ensures that the default matches between pre/post synthesis. Some synthesis tools take the default case as a suggestion only. 3. Usually makes the description both more compact and easier to understand. I suggest setting int_D to a default of x"FF", and the other outputs to 'Z' ( shared controller ), or '1' ( single master ). The set-up violation should also show-up in the post P&R timing report. I think this is just too much delay for an apparent 90MHz clock. I hope some of this helps. Regards, "John Williams" <j2.williams@qut.edu.au> wrote in message news:3CD8B1EF.A2C312C8@qut.edu.au... > Hi folks, > > I've developed a simple state machine targetted at an XC4010 FPGA, which > writes values to an external SRAM. > > The state machine is simple, and behavioural simulation looks perfect. > The general concept is that a data value gets placed on the inputs, my > design is strobed, it latches the input, asserts the data and address > bus, then strobes the RAM to write the value. After the RAM is strobed, > the address and data bus are un-asserted, and the address pointer > incremented. Then it starts all over again. > > I have 8 clock cycles between strobe events, so took a conservative > approach to the design, whereby the RAMs address and data buses are > asserted 1 cycle before the RAM is strobed, and held stable for one > cycle afterwards, to prevent the address or data changing while the RAM > is writing. > > As I said, the design does a behavioural sim perfectly, but when I do a > post P&R sim it fails completely, with the outputs all going undefined > very soon after the sim starts. I downloaded the design to the chip > and, unsurprisingly, it failedto work there either! > > I am using a 3 process model for the state machine. The first process > registers the state variable, the second process performs the state > transitions, and the 3rd drives the outputs as a function of the current > state. > > Following is the VHDL code for my design, I hope it's not too long for > someone to take a look and give me some tips. Another point of note, > when I do the post P&R sim I get the followign warnings, but am unsure > quite how to respond to fix whatever is causing it. > > # ** Warning: */X_FF SETUP Low VIOLATION ON I WITH RESPECT TO CLK; > # Expected := 1.3 ns; Observed := 0.525 ns; At : 10.94 ns > # Time: 10940 ps Iteration: 0 Instance: > /testbench/uut/cur_state_reg_2_i_1 This looks like routing delay on the state machine FF's. The time implies that you are trying to run a 4010 at 90MHz. That seems kind of fast for that old part. Have you set your clock frequency correctly? > > Here is th ecode. Thanks in advance for any help. > > John > > --begin ram_writer.vhd > -- A Simple SRAM output driver. 8 bit data are clocked in and written > to > -- a 32K SRAM attached to the CEB, OEB, WEB, A and D lines > -- Each successive byte is written to the next address, up to 0x7FF > -- WEB, CEB and OEB are all active low RAM control signals > > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > use IEEE.STD_LOGIC_ARITH.ALL; > use IEEE.STD_LOGIC_UNSIGNED.ALL; > > entity ram_writer is > Port ( reset : in std_logic; > clk : in std_logic; > strobe : in std_logic; > d_in : in std_logic_vector(7 downto 0); > en : in std_logic; > ceb : inout std_logic; > oeb : inout std_logic; > web : inout std_logic; > a_out : inout std_logic_vector(14 downto 0); > d_out : inout std_logic_vector(7 downto 0)); > end ram_writer; > > architecture Behavioral of ram_writer is > > signal pointer : integer range 0 to 32767; > signal int_data : std_logic_vector(7 downto 0); > > -- an internal signal to enable the outputs (Except ceb) > signal oen : std_logic; > > type state_type is (init,ready, latch, write1, write2, > update, wait_strobe_low, finished); > > signal cur_state, next_state : state_type; > > begin > > -- tristate the address and data outputs on the "oen" signal > a_out <= conv_std_logic_vector(pointer,15) when oen='1' > else (others => 'Z'); > > d_out <= int_data when oen='1' > else (others => 'Z'); > > -- RAM control signals are active low > -- output enable bit on RAM. > oeb <= '1' when oen='1' else -- disable if we are in control > 'Z'; > > -- doing burst mode transfer, so hold write on, and strobe with chip > select > web <= '0' when oen='1' else > 'Z'; > > -- register the state variable > state_reg:process(reset,clk) > begin > if(reset='1') then > cur_state <= init; > elsif(clk'event and clk='1') then > if(en='1') then > -- normal state progression > cur_state <= next_state; > else > -- hold in init state if en='0' > cur_state <= init; > end if; > end if; > end process; > > -- state transition process > state_update:process(cur_state,d_in,strobe) > begin > case cur_state is > when init => > pointer <= 0; > int_data <= (others => '0'); > > next_state <= ready; > > when ready => > if(strobe='1') then > -- latch the data off the input > int_data <= D_in; > next_state <= latch; > else > next_state <= ready; > end if; > > when latch => > next_state <= write1; > > when write1 => > next_state <= write2; > > when write2 => > next_state <= update; > > when update => > -- increment the pointer > if pointer<32767 then -- don't wrap past top of RAM > pointer <= pointer+1; -- increment the address for next time > next_state <= wait_strobe_low; > else > next_state <= finished; > end if; > > when wait_strobe_low => > if (strobe='0') then > next_state <= ready; > else > next_state <= wait_strobe_low; > end if; > > when finished => > next_state <= finished; > > when others => > next_state <= init; > > end case; > end process; > > -- defines the outputs based on the current state > outputs: process(cur_state) > begin > case cur_state is > when init => > -- disable outputs, don't drive RAM chip select > oen <= '0'; > ceb <= 'Z'; > > when ready => > -- disable the outputs and don't assert the RAM chip select > oen <= '0'; > ceb <= 'Z'; > > when latch => > -- assert the outputs but don't drive the chip select yet > oen <= '1'; > ceb <= 'Z'; > > when write1 => > -- assert outputs and drive chip select > oen <= '1'; > ceb <= '0'; > > when write2 => > -- unassert chip select > ceb <= 'Z'; > > when update => > -- disable the outputs > oen <= '0'; > ceb <= 'Z'; > > when wait_strobe_low => > oen <= '0'; > ceb <= 'Z'; > > when finished => > null; > > when others => > null; > > end case; > end process; > > end Behavioral;Article: 42944
Hi , I'm working on a project which involves a xilinx's virtex-ii fpga. the core of this fpga will run with a 125 MHz clock and interface with a 250 MHz data rate DDR SRAM. I would like to know whether xilinx have a reference design of a DDR SRAM controller. and if not , would it be smart to use the QDR referance design (xapp 262) with some modifications , as a DDR controller? Thanks Eyal.Article: 42945
"John Williams" <j2.williams@qut.edu.au> wrote in message news:3CD8B1EF.A2C312C8@qut.edu.au Hi John, I had a similar problem of a perfectly simulating state machine for functional simulation that completely flopped on timing simulation after synthesis. I've not looked at your code in detail but my general tip is to slow the clock down until your design works and then it will be necessary to delve into the methods to speed up your logic to get the clock rate you want. This may take some time depending on your speed requirements. There are also some good tips at :- http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=9411 Let us know how you get on. Regards Phil -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 42946
I'm working with spartan2 and I've read in a document about "configuration checklist" that you can set your unused I/Os as outputs tied to ground to add extra grounding to a device . NOw I have this problem that I don't know if I can tie my I/O(Vref) pins to ground too or not. also I'm not sure about the I/O(IRDY) and I/O(TRDY) pins . should I treat all these pins as I/O or not. thanks for your helpArticle: 42947
"jerry1111" <jerry1111@wp.pl> writes: > > We've comitted to it (but haven't gotten it yet) I'm getting worried... Should > > we have gone with NIOS??!? > > Don't worry ;) > I've been waiting for my piece of Nios for 3 weeks. BTW: I saw a demo of a NIOS CPLD running Linux a couple weeks ago... Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 42948
This is a multi-part message in MIME format. --------------95FDFEA6509D0E7636AA8615 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hallo, Are the TAP pins 5V tollerant in SpartanII/Virtex/VirtexII devices? -- Regards, Pawel J. RajdaArticle: 42949
arast@inficom.com (Alex Rast) writes: > I'm involved in a commercial project with projected volumes into the 100's of > thousands if not millions per month. We've got a PCI card, and we've decided > to implement the PCI interface in an FPGA, along with multiple other > functions. For volumes like that I would go for an ASIC using a PCI core where you can get the HDL source (Synopsys, RaviCAD etc.). You can of course make a FPGA prototype using the same core which will let you test your design with all the various host bridges available. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.com
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