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
On 18 Mar 2005 12:09:04 -0800, lecroy7200@chek.com wrote: > >After running an automated test for the last 24 hours, finally one part >on my test unit failed. Because the software would try and program the >devices after a fixed amount of time in order to detect the fault, I am >not sure if the pins were in this state at the time of the failure. >However, Looking at the the control pins, HDC is high, LDC is low, >done/pgm' is low and init is low. > >I increased the reset time to over a second with no luck. I tried >reloading the device over 50 times with no luck. This is what we are >seeing. I am not sure why it entered this mode and if it had anything >to do with my testing, or was just its time. > >I have left the device in this state is anyone has ideas on further >test. Great. As I have read further, you no longer have it in this state. Assuming you get it into this failed state again, please try the followig 2 things: 1) supply a continuous CCLK, with DIN alternating 0 and 1. Please tell us what you see on the DOUT pin. 2) Supply a continuous CCLK for at least 2**24 cycles (16 million cycles) plus a few extra 100000 cycles. At 1 MHz, this will take about 16 seconds. Set DIN to 1 for all of this. Please report any changes you observe on Done/Prog, HDC, LDC, and DOUT. There is a "fault " mode where if it gets some clock cycles that are unexpected at the beginning, or corruption of the header it can take 16000000 clocks for it to get back to the beginning of the state sequence. I am suspecting that the note by Hal Murray of a week ago may be occuring, although your observation are also in line with guess of Brownout. Just as a reminder, here what Hal Wrote: >I think there is a combined ~prog and done pin. It's pulled low >(open drain) by the 3000 until it gets configured. Power up starts >needing configutation. A high-to-low transition on ~prog asks for >another configuration cycle. If your attempted configuration gets >confused, there is no way to start over until you finish configuration >since ~done is held low so you can't make it go high-to-low. > >Configuration starts with a 24 bit bit-count value. After that many >configuration clocks, all the devices in the the chain release >their done pulldown. If one of the devices in the chain gets >(somehow) a low value in that counter you have to cycle through >2**24 cycles to wrap around and finish the current cycle. Keep working on it, Philip Philip Freidin FliptronicsArticle: 81201
Dear Franceso! Congratulation for the C compiler working with PicoBlaze! It's a great idea, and a much more faster way of code evaluation. Would you please send me a copy of the compiler and the "partially written" user manual for a test? Thanks! E-mail: Sir_Pal13@hotmail.com Best regards: Sir PalArticle: 81202
Hi everyone,
I try to construct this statemachine as described in VHDL below:
(the machine is supposed to set the hold as soon as the trig-signal is
asserted (initialized only when all signals have been low for a
clock-cycle) and go low when both the read and holdoff signals have been
asserted for some time...
------------------------------------------
entity holdoffcontroller is
Port ( clk : in std_logic;
reset : in std_logic;
save : in std_logic;
trig : in std_logic;
read : in std_logic;
holdoff : in std_logic;
hold : out std_logic;
state : out std_logic_vector(4 downto 0));
end holdoffcontroller;
architecture Behavioral of holdoffcontroller is
constant stateStart : std_logic_vector(4 downto 0) := "00001";
constant stateWait : std_logic_vector(4 downto 0) := "00010";
constant stateTrigger : std_logic_vector(4 downto 0) := "00100";
constant stateHold : std_logic_vector(4 downto 0) := "01000";
constant stateRead : std_logic_vector(4 downto 0) := "10000";
begin
STATEMACHINE: block
signal current_state, next_state : std_logic_vector(4 downto 0)
:= stateStart;
begin
stateRegister : process(clk, reset)
begin
if reset = '1' then
current_state <= stateStart;
elsif rising_edge(clk) then
current_state <= next_state;
end if;
end process;
stateTransitions : process(current_state, holdoff, read, trig)
begin
-- stateStart
if current_state(0) = '1' then
hold <= '0';
if holdoff = '0' and read = '0' and trig = '0' then
next_state <= stateWait;
end if;
end if;
-- stateWait
if current_state(1) = '1' then
if trig = '1' then
next_state <= stateTrigger;
end if;
end if;
-- stateTrigger
if current_state(2) = '1' then
hold <= '1';
if holdoff = '1' and read = '0' then
next_state <= stateHold;
end if;
if holdoff = '0' and read = '1' then
next_state <= stateRead;
end if;
if holdoff = '1' and read = '1' then
next_state <= stateStart;
end if;
end if;
-- stateHold
if current_state(3) = '1' then
if read = '1' then
next_state <= stateStart;
end if;
end if;
-- stateRead
if current_state(4) = '1' then
if holdoff = '1' then
next_state <= stateStart;
end if;
end if;
end process;
state <= current_state;
end block;
end Behavioral;
------------------------------------------
Simulating the behavioral model works just fine, but when simulating the
Translate-model the function of the model is just awkward!
When synthesis runs i get these warnings:
WARNING:Xst:647 - Input <save> is never used.
WARNING:Xst:737 - Found 1-bit latch for signal <hold>.
WARNING:Xst:737 - Found 5-bit latch for signal <next_state>.
Found 5-bit register for signal <current_state>.
Furthermore I get these three strange clock-signals:
-----------------------------------+------------------------+-------+
Clock Signal | Clock buffer(FF name) | Load |
-----------------------------------+------------------------+-------+
_n0066(_n006637:O) | NONE(*)(next_state_4) | 4 |
clk | BUFGP | 8 |
current_state_0:Q | NONE | 1 |
-----------------------------------+------------------------+-------+
(*) This 1 clock signal(s) are generated by combinatorial logic,
and XST is not able to identify which are the primary clock signals.
Please use the CLOCK_SIGNAL constraint to specify the clock signal(s)
generated by combinatorial logic.
INFO:Xst:2169 - HDL ADVISOR - Some clock signals were not automatically
buffered by XST with BUFG/BUFR resources. Please use the buffer_type
constraint in order to insert these buffers to the clock signals to help
prevent skew problems.
Can anybody tell me what I do wrong in the design of the statemachine!
Thanks for helping me out!
Article: 81203"news.verizon.net" <res0rsef@verizon.net> schrieb im Newsbeitrag news:DZK_d.4272$uw6.817@trnddc06... > Hi, > I would like some help from roketio users to find what is the maximum > realizable freq we can get out of it. I hear that although it supports upto > 3.125Ghz, you can only get only upto 2.5Ghz. Also, can I get any eval board 3.125 Gbit/s, not GHz. This is the line data rate. Effective data rate is only 2.5 Gbits/s due to line encoding using 8B/10B encoder (encodes 8 data bits into 10 data bits to guarantee a constant DC level and transition density) Virtex4 supports also 64B/66B encoding (which is much more effcient). Regards FalkArticle: 81204
Well, I don't remember seeing anything on FCCM 2005 in this news group,
and I just got this email today. Cheap seats end this Sunday Night.
I'll be there!
==================
C A L L F O R P A R T I C I P A T I O N
THE THIRTEENTH ANNUAL
IEEE SYMPOSIUM ON FIELD PROGRAMMABLE
CUSTOM COMPUTING MACHINES
Napa, California
April 17 - 20, 2005
http://www.fccm.org
Register now! The FCCM pre-registration deadline is Sunday, 20 March.
Advance registration will be accepted by mail, fax, or online
submission through 20 March 2005. After 20 March, you must pay late
registration fees. After 3 April only on-site registration will be accepted.
All no-show registrations will be billed in full. Students are
required to show current picture ID cards at the time of registration.
To register, please visit the FCCM home page at http://www.fccm.org.
The registration application accepts MasterCard, Visa, American
Express, and Diners Club cards. If you do not have one of these credit
cards, or if you prefer not to register online, please print out the
form and fax or mail with payment, to:
IEEE Computer Society
ATTN: FCCM '05 Registration
Dept. 6006
Washington, DC 20042-6006
(202) 371-0101 Phone
(202) 728-0884 FAX
Sorry, no phone registrations.
Please make checks payable to IEEE Computer Society.
Registrations received without payment will not be accepted.
Please remember to make hotel accomodations, too!
FCCM '05
Preliminary Program
________________________________________________________________
Sunday 17 April 2005
Registration and reception, 7:00pm -- 9:00pm
________________________________________________________________
Monday 18 April 2005
Session 1: Applications I
8:30 -- 10:00
Title: Efficient Hardware Data Mining with the
Apriori Algorithm on FPGAs
Authors: Zachary K. Baker, Viktor K. Prasanna
Organization: University of Southern California
Title: A Novel 2D Filter Design Methodology for
Heterogeneous Devices
Authors: Christos-Savvas Bouganis, George A.
Constantinides, Peter Y.K. Cheung
Organization: Imperial College
Title: Prototyping Architectural Support for
Program Rollback Using FPGAs
Authors: Radu Teodorescu, Josep Torrellas
Organization: UIUC
________________________________________________________________
Poster Session 1
10:00 -- 11:00
________________________________________________________________
Session 2: Architecture
11:00 -- 12:00
Title: Register File Architecture Optimization
in a Coarse-Grained Reconfigurable Architecture
Authors: Zion Kwok, Steven J.E. Wilton
Organization: University of British Columbia
Title: Handling Different Computational
Granularity by a Reconfigurable IC featuring
Embedded FPGAa and a Network-on-Chip
Authors: Francesco Lertora, Michele Borgatti
Organization: ST Microelectronics
________________________________________________________________
Session 3: Tools I
1:30 -- 3:00
Title: A Study of the Scalability of On-Chip
Routing for Just-in-Time FPGA Compilation
Authors: Roman Lysecky, Frank Vahid, Sheldon X.-D. Tan
Organization: University of California, Riverside
Title: Simplifying the Integration of Processing
Elements in Computing Systems using a
Programmable Controller
Authors: Lesley Shannon, Paul Chow
Organization: University of Toronto
Title: Evaluation of Code Generation Strategies
for Scalar Replaced Codes in Fine-Grain
Configurable Architectures
Authors: Pedro C. Diniz
Organization: University of Southern California/ISI
________________________________________________________________
Poster Session 2
3:00 -- 4:00
________________________________________________________________
Session 4: Graphics
4:00 -- 5:00
Title: FPGA Particle Graphics Hardware
Authors: John S. Beeckler, Warren J. Gross
Organization: McGill University
Title: Reconfigurable Designs for Radiosity
Authors: Paul Baker, Tim Todman, Henry Styles,
Wayne Luk
Organization: Imperial College
________________________________________________________________
Demo Night
7:00 -- 9:00
________________________________________________________________
Tuesday 19 April 2005
Session 5: Applications II
8:30 -- 10:00
Title: Hardware Factorization Based on Elliptic
Curve Method
Authors: Martin Simka, **Jan Pelzl, ***Thorsten
Kleinjung, Milos Drutarovsky, ****Viktor
Fischer, **Christof Paar
Organization: Technical University of Kosice, Ruhr
University**, University of Bonn***,
Universite Jean Monnet****
Title: Metropolitan Road Traffic Simulation on
FPGAs
Authors: Justin L. Tripp, Henning S. Mortveit,
Anders A. Hansson, Maya Gokhale
Organization: Los Alamos National Laboratories
Title: Time Domain Numerical Simulation for
Transient Wave Equations on Reconfigurable
Coprocessor Platform
Authors: Chuan He, Wei Zhao, Mi Lu
Organization: Texas A&M University
________________________________________________________________
Poster Session 3
10:00 -- 11:00
________________________________________________________________
Session 6: Run Time
11:00 -- 12:00
Title: COMA: A COoperative MAnagement Scheme for
Energy Efficient Implementation of Real-Time
Operating Systems on FPGA Based Soft Processors
Authors: Jingzhao Ou, Viktor K. Prasanna
Organization: University of Southern California
Title: An Execution Environment for
Reconfigurable Computing
Authors: W. Fu, K. Compton
Organization: University of Wisconsin at Madison
________________________________________________________________
Session 7: Arithmetic
1:30 -- 3:00
Title: Higher Radix Floating-Point
Representations for FPGA-Based Arithmetic
Authors: Bryan Catanzaro, Brent Nelson
Organization: Brigham Young University
Title: An Analysis of the Double-Precision
Floating-Point FFT on FPGAs
Authors: K. Scott Hemmert, Keith Underwood
Organization: Sandia National Laboratories
Title: A Comparision of Floating Point and
Logarithmic Number Systems for FPGAs
Authors: Michael Haselman, Michael Beauchamp,
Aaron Wood, Scott Hauck, *Keith Underwood, *K.
Scott Hemmert
Organization: University of Washington, Sandia National
Laboratories*
________________________________________________________________
Poster Session 4
3:00 -- 4:00
________________________________________________________________
Session 8: Device Architecture
4:00 -- 5:00
Title: Terrestrial-Based Radiation: A Cautionary
Tale
Authors: Heather Quinn, Paul Graham
Organization: Los Alamos National Laboratory
Title: Automating the Layout of Reconfigurable
Subsystems using Circuit Generators
Authors: Shawn Phillips, Scott Hauck
Organization: University of Washington
________________________________________________________________
Wednesday 20 April 2005
Session 9: Networking
8:30 -- 10:00
Title: Fast Reconfiguring Deep Packet Filter for
1+ Gigabit Network
Authors: Young H. Cho, William H. Mangione-Smith
Organization: UCLA
Title: A Framework For Rule Processing in
Reconfigurable Network Systems
Authors: Michael E. Attig, John W. Lockwood
Organization: Washington University in St. Louis
Title: A Signature Match Processor Architecture
for Network Intrusion Detection
Authors: Janardham Singaraju, Long Bu, John A.
Chandy
Organization: University of Connecticut
________________________________________________________________
Session 10: Tools II
10:30 -- 11:30
Title: Interleaving Behavioral and Cycle-
Accurate Descriptions for Reconfigurable
Hardware Compilation
Authors: Jose Gabriel F. Coutinho, Jun Jiang,
Wayne Luk
Organization: Imperial College
Title: Modeling and FPGA Implementation of
Applications using Parameterized Process
Networks with Non-Static Parameters
Authors: Hristo Nikolov, Todor Stefanov, Ed
Deprettere
Organization: Leiden University
Philip Freidin
Fliptronics
Article: 81205>Thanks for that but I already knew it existed: I wasn't trying to pretend I >had invented something. But my original question was why isn't it more >widely used? It is widely used - at least if you are generous on what "it" is. There are two conflicting properties you want when transmitting data over a link. You need transitions in the data stream so the receiver can do clock recovery. But useless transitions reduce link bandwidth efficiency. Another goal is to make the data stream ballanced so you can run it through a capicator or transformer. Manchester is very easy to implement with good DC ballancing but only 50% efficient. 4B/5B (FDDI) is 80% efficient but not quite ballanced in some cases. 8B/10B is ballanced but more complicated to implement. Typical async RS-232 is 80% efficient and easy to implement as long as the signal is clean (aka distance is short relative to the bit rate). If you have long links, the fiber/cable is the expensive part and you are willing to work harder (pay more) on clock recovery to get more bits through the pipe. On the other hand, for something like Ethernet or RS-232 with short links, you are generally willing to trade link bandwidth (or distance) for simpler decoding procedures. For an alternative approach, google for scrambling as used on SONET. The general idea is to start with a good clock recovery circuit (say 50 bits without any transitions) and then randomize the data stream by XORing it with a random pattern so you still have transitions if the user sends all 0s or whatever the nasty pattern is. -- 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: 81206
I'm looking for a development board to implement an MPEG-2 video decoder,
and currently interested in ADS-XLX-SP3-DEV1500 available from Avnet, which
comes with the following components:
* Xilinx XC3S1500/2000-FG676 Spartan-3 FPGA
* 2x16 character LCD
* 128x64 OSRAM OLED graphical display
* DB15 & video DAC
* Audio CODEC
* PS2 keyboard & mouse ports
* 8-position DIP switch
* 2 push-buttons
* 8 discrete LEDs
* Piezo buzzer
* 3, 140-pin general purpose I/O expansion connectors (AvBus)
* Up to 30 LVDS pairs
* 1, 50-pin 0.1" header for easy I/O access
* Micron DDR SDRAM (32 MB)
* 16 MB FLASH
* 2 MB SRAM
* RS-232 serial port
* 10/100 Ethernet
* USB 2.0
* Xilinx platform FLASH configuration PROM(s)
* Parallel IV cable support for JTAG
* Fly-wire support for Parallel III and MultiLINX™
The peripherals seem more than enough, but I still wonder whether the logic
resources in XC3S1500 is sufficient.
Any suggestion is really appreciated.
Thanks,
Kevin
----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web -----
http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net
Article: 81207"Peter Særensen" <pbs@mortician.dk> wrote in message news:ee8cc3e.-1@webx.sUN8CHnE... > Hi, > > Im a poor student who purchased the 6.3 version of the EDK a few months > back. Uptill now I have been using the evaluation version of ISE 6.3 (too > expensive for me). I have been unable to use the WebPack version of the > ISE 6.3 since "all" I have is a Virtex4 LX25. I had been planning to > switch to the ISE 7.1 webpack (which supports my device) but I am unable > to get it working with my EDK 6.3 installation. I get the following error: > > $XILINX does not point to an iSE 6.3 installation > > Isnt it possible to use the ISE 7.1 webpack with EKD 6.3 ?? > > thanks I thought you need to have the same version of both to get them to work properly Either go back to ise 6.3 or wait for edk 7.1 Usually better off staying behind a version or two Can download old versions of web pack http://www.xilinx.com/webpack/classics/wpclassic/index.htm If your a university student surely your university can request the full software via XUP Xilinx university program. http://www.xilinx.com/univ/index.htm http://xup.msu.edu/ Another option would be to buy a textbook with or by itself the student version of 6.3 which is same as full ise but without any support. http://www.amazon.com/exec/obidos/tg/detail/-/0131858394/qid=1111234703/sr=2-1/104-7812736-3159945?v=glance&s=books AlexArticle: 81208
Hi kevin@nospam.nospam wrote: > I'm looking for a development board to implement an MPEG-2 video decoder, > and currently interested in ADS-XLX-SP3-DEV1500 available from Avnet, which > comes with the following components: > * Xilinx XC3S1500/2000-FG676 Spartan-3 FPGA > * 2x16 character LCD > * 128x64 OSRAM OLED graphical display > * DB15 & video DAC > * Audio CODEC > * PS2 keyboard & mouse ports > * 8-position DIP switch > * 2 push-buttons > * 8 discrete LEDs > * Piezo buzzer > * 3, 140-pin general purpose I/O expansion connectors (AvBus) > * Up to 30 LVDS pairs > * 1, 50-pin 0.1" header for easy I/O access > * Micron DDR SDRAM (32 MB) > * 16 MB FLASH > * 2 MB SRAM > * RS-232 serial port > * 10/100 Ethernet > * USB 2.0 > * Xilinx platform FLASH configuration PROM(s) > * Parallel IV cable support for JTAG > * Fly-wire support for Parallel III and MultiLINX™ > > The peripherals seem more than enough, but I still wonder whether the logic > resources in XC3S1500 is sufficient. > Any suggestion is really appreciated. I'd say yes. http://www.4i2i.com/downloads/AllianceCoreMPEG4Decoder.pdf This is a MPEG4 decoder in <1600 Slices ... The 1500 has > 10000 Slice IIRC so ... SylvainArticle: 81209
kevin@nospam.nospam wrote: > I'm looking for a development board to implement an MPEG-2 video decoder, > and currently interested in ADS-XLX-SP3-DEV1500 available from Avnet, which > comes with the following components: > * Xilinx XC3S1500/2000-FG676 Spartan-3 FPGA > * 128x64 OSRAM OLED graphical display > * DB15 & video DAC > * Audio CODEC > * PS2 keyboard & mouse ports [... snip stuff like the Piezo buzzer and connectors ...] > * Micron DDR SDRAM (32 MB) > * 16 MB FLASH > * 2 MB SRAM > * 10/100 Ethernet > * USB 2.0 [...] > The peripherals seem more than enough, but I still wonder > whether the logic resources in XC3S1500 is sufficient. Howdy Kevin, That's quite a development board! Seems like it would be perfect for your project and you should have no problems fitting an mpeg decoder in that device. Compared to past FPGA's, XC3S1500 is quite a large device - in fact, Xilinx has an IP partner that has a mpg decoder core which fits in a 3S1000: http://www.xilinx.com/bvdocs/ipcenter/data_sheet/Amphion_CS6651.pdf I see that their core runs at only 50 MHz. With just a little bit of attention, running at 100 MHz in the S3 should not be a problem. Going out on a limb just a bit (it's a pretty strong one), you could likely code up two decoders in the space of their one, or one decoder that takes up half the space of theirs. Have fun, MarcArticle: 81210
Hal Murray wrote: > >Thanks for that but I already knew it existed: I wasn't trying to pretend I > >had invented something. But my original question was why isn't it more > >widely used? > > It is widely used - at least if you are generous on what "it" is. Like if "it" can be equal to Ethernet? :-) > Manchester is very easy to implement with good DC ballancing but > only 50% efficient. 4B/5B (FDDI) is 80% efficient but not quite > ballanced in some cases. 8B/10B is ballanced but more complicated > to implement. Just to make this this discussion complete, with 64B/65B and 64B/66B there are finally encoding schemes with efficiencies worth being proud of. [...] > For an alternative approach, google for scrambling as used on SONET. > The general idea is to start with a good clock recovery circuit (say > 50 bits without any transitions) and then randomize the data stream > by XORing it with a random pattern so you still have transitions if > the user sends all 0s or whatever the nasty pattern is. A CID (consecutive identical digits) of 50 bits will cover most real-world cases of scrambled SONET traffic, but I'd personally want a CDR with noticably more staying power than that. Have fun, MarcArticle: 81211
Hello everyone, I have a rather high performance design that acts as a high through-put data path with some DSP manipulation on the way through. I had been rather certain that I was going to move through to production using Stratix/Stratix II parts. However, the other day I sat down with a distributor who was able to point out some very interesting items for comparisons with the V4 chips. Here are the four main items brought up: 1) Faster RAM 2) Potentially Lower power consumption 3) Price-points in the $120-160 range 4) More flexibility on the parallel LVDS inputs to the chip I'm interested to hear anyone with first hand comparisons between the V4 and other chips. Thanks, KeithArticle: 81212
Preben Holm wrote:
> Hi everyone,
[...]
Really a comp.lang.vhdl question, but since you're here... at the
beginning of your process (right after the begin), I think you'd want a
default assignment for next_state:
next_state <= current_state;
This will make it obvious to the tools that they should remain in the
current state unless one of the following conditions turns out to be
true.
> stateTransitions : process(current_state, holdoff, read,
trig)
> begin
> -- stateStart
> if current_state(0) = '1' then
> hold <= '0';
>
> if holdoff = '0' and read = '0' and trig = '0' then
> next_state <= stateWait;
> end if;
> end if;
>
[...]
> WARNING:Xst:737 - Found 5-bit latch for signal <next_state>.
> Found 5-bit register for signal <current_state>.
The latch warning for next_state is your clue.
Good luck,
Marc
Article: 81213Keith Williams wrote: > Hello everyone, > > I have a rather high performance design that acts as a high through-put data > path with some DSP manipulation on the way through. > > I had been rather certain that I was going to move through to production > using Stratix/Stratix II parts. However, the other day I sat down with a > distributor who was able to point out some very interesting items for > comparisons with the V4 chips. > > Here are the four main items brought up: > > 1) Faster RAM > 2) Potentially Lower power consumption > 3) Price-points in the $120-160 range > 4) More flexibility on the parallel LVDS inputs to the chip > > I'm interested to hear anyone with first hand comparisons between the V4 and > other chips. Howdy Keith, If you register the output of the BRAM, then yes, it's probably faster. Otherwise, probably not. Do you need that much speed? You didn't really give any design info (target speeds, device/design size, etc). There was a considerable "debate" on comp.arch.fpga last month about the power differences between the S2 and V4, and while I am positive that the Virtex-4 static power is lower, I am less convinced that when a high speed design is running in the device that is well utilized, the total power will be THAT much different between the two. Device size factors into the power equation as well. In short, he _might_ be right on any or all accounts, but until you actually have a price quote in your hand from each vendor for a selected part, and target your design to get design speeds, and run the power estimators for each, it is too close to call, IMO. The ISERDES and OSERDES are quite neat features though, and when combined with the no-brainer local routing and clock divider, may make a compelling sell on its own. Good luck, MarcArticle: 81214
Hi, I would make a few of suggestions : * use an enumeration and traditional "case state is when =>" construct. This facilitates a lot of things, if only for the synthesis tool to properly recognize your FSM, but also for HSL simulation, readability, reliability, optimization etc... * to output the state vector, use a simple decoder (which will be probably eliminated by synthesis). And maybe you don't want the one-hot vector vector to come out, but an binary (more compact) version ? * Single-process style is easier to write (imo) and not prone to the usual errors in combinational processes. (you're not the first and not the last to get caught) You can even write Moore style in one process if you don't want to move your actions in the transitions. * Keep in mind that the synthesizer sometimes can guess the "parallel case" and sometime can't. This is likely your case (can't guess). It should have trouble understanding that individual bit comparisons are (probably) mutually exclusive. So I'm afraid it would code the priority you've told him implicitly to implement (last "if" does win). I think this is inefficient synthesis-wise. On my Website, you'll find many FSM examples, FWIW http://www.alse-fr.com/English/ips.html I never really liked the "textbook" two-processes style, and I've seen lots of problems in code written this way... But Text editors, FSM coding and VHDL vs Verilog are almost religious issues :-) ... Bert Preben Holm wrote: > Hi everyone, > > I try to construct this statemachine as described in VHDL below: > (the machine is supposed to set the hold as soon as the trig-signal is > asserted (initialized only when all signals have been low for a > clock-cycle) and go low when both the read and holdoff signals have been > asserted for some time... > > ------------------------------------------ > entity holdoffcontroller is > Port ( clk : in std_logic; > reset : in std_logic; > save : in std_logic; > trig : in std_logic; > read : in std_logic; > holdoff : in std_logic; > hold : out std_logic; > state : out std_logic_vector(4 downto 0)); > end holdoffcontroller; > > architecture Behavioral of holdoffcontroller is > constant stateStart : std_logic_vector(4 downto 0) := "00001"; > constant stateWait : std_logic_vector(4 downto 0) := "00010"; > constant stateTrigger : std_logic_vector(4 downto 0) := "00100"; > constant stateHold : std_logic_vector(4 downto 0) := "01000"; > constant stateRead : std_logic_vector(4 downto 0) := "10000"; > begin > > STATEMACHINE: block > signal current_state, next_state : std_logic_vector(4 downto 0) > := stateStart; > begin > stateRegister : process(clk, reset) > begin > if reset = '1' then > current_state <= stateStart; > elsif rising_edge(clk) then > current_state <= next_state; > end if; > end process; > > > stateTransitions : process(current_state, holdoff, read, trig) > begin > -- stateStart > if current_state(0) = '1' then > hold <= '0'; > > if holdoff = '0' and read = '0' and trig = '0' then > next_state <= stateWait; > end if; > end if; > etc..Article: 81215
vax, For 5V inputs to the Spartan 3, you may also use 100 ohm series resistors from the 5V logic to the S3 inputs. If you really want to cut costs, use a 1N4001 diode to drop the 3.3V to ~ 2.6 volts for Vccaux. Just be sure you have some reasonable value electolytic as bypass to ground on the Vccaux (like 100uF), along with the recommended bypass caps (0.01uf - 0.1uf). The penalty of not having a perfect 2.50V voltage is that the LVDS outputs will have a few tens of millivolt higher common mode (basically, a don't care). Austin vax, 9000 wrote: > Group, > Well, I need to choose between XC3S50 and EPM1270. Both have pros and > cons. I list them below, and I'd like to ask you to point out other > important issues, and which would you choose if you were me. > > My circuit occupies around 50% of XC3S50 or EPM1270. I might need several > tens of the chips finally, But at this point I just need 1-3 for the > prototype. I am aming at TQ144 package. It needs to interface 5V TTL logic. > I plan to use 3.3V LVT244/245 to shift the voltage for inputs. I didn't > check 5V/2.5V voltage shifters. My circuit is slow, working with 20MHz > clock. > > XC3S50 pros: > * Pin compatible SC3S200 available for possible growth > * Cheap ($12+ for XC3S50, $15+ for XC3S200 at XILINX online store) > * RAM on chip. Good if I want to add a small FIFO in the future > cons: > * Don't know where to buy XCF01S configuration flash. cost? > * Needs both 2.5V and 3.3V power supply to interface 3.3V logic > > EPM1270 pros: > * On chip configuration flash > * On chip user flash, if I want to store some bits in the future > * Need only single 3.3V power supply to interface 3.3V logic > cons: > * expensive (EPM1270C5ES $25+ at digikey). May cost more for none-ES? > (for example, EPM1270C3 costs $73) > * No TQ144 pin compatible bigger chips > > cheers, > vax, 9000 >Article: 81216
Hi, There is an LM70 (uWire / SPI) Temperature Sensor on our Tornado board, and the VHDL code for the digital thermometer is free ! http://www.alse-fr.com/Tornado/Torn_Educ_us.pdf We have also a reference design for the MaxII board with a different temperature sensor (external transistor as sensor) : Max6627 This kind of interface is about 60 lines of (easy) code... really simple. I also wrote behavioral models for the Temperature sensors so the design can be verified by simulation. Best regards, Bert rgebru wrote: > Hi, > > I'm thinkin go of designing a heating/cooling system with VHDL and > need to interface my Spartan 3 board to a real temp sensor. Does > anyone have an idea of how I can do this? > > Thanks!! >Article: 81217
Keith, The power story is a very good one, and we have the data to prove it. When the chip is actually operating (only time you would care), the junction temoerature is bound to increase. Then the static power different really stands out (>2X improvement, worst case, typically 4X better). The dynamic interconnect power for the two is equal. Our dynamic BRAM power is half that in S2. That can be a few watts in a DSP design. The DSP48 when arranged to use the internal dedicated cascading paths has 1/8th the power of the S2 solution. Bottom line: a high, end fast DSP design may disspate half the power in V4 over S2. And the junction temperature will be at least 15 degress lower (for equivalent heatsinks) making heatsinking or airflow less costly as well. That is why we are taking previously "won" sockets away from S2 for G4 basestations. Heat is the #1 enemy of all wired and wireless network equipment, because heat means energy, and energy means more batteries, and less holdover time, and more air conditioning costs in the central office, and more failures in the field. We also have the SX25, SX35, and SX55 which are optimized for DSP applications, to provide a lower cost part to get the same amount of DSP resources. There is NO COMPETITION AT ALL from Altera here: it DOESN'T EVEN EXIST. AustinArticle: 81218
Hi all, I'm implementing a Digital Down Converter for Virtex II pro device. I think I'll not use the builtin DDC IP core because I'm using this project to learn something about FPGAs and VHDL. Essentially I have samples coming from an A/D at 64MHz. The signal is bandpass, centered at 112 MHz and it can have to different bandwidth 5MHz and 25MHz. I've already implemented in VHDL the I and Q components splitting, now I have to filter these signals with low pass filter and decimate the sequence. I'm going to use the "MAC FIR Filter" IP core (shipped with Xilinx ISE). I have some questions, I'm a newbie digital designer so please consider this :-) 1) using a polyphase decimator is exactly the same of using a single rate filter and then downsampling the output? 2) I need the same filter on both I and Q channels, so I think I could set the core to use 2 channels, but I'm not sure how it works, is it realized with time sharing? I'd need the two samples I(k) Q(k) at the same time. Thank you all, and -- I tried switching to gum but I couldn't keep it lit. |\ | |HomePage : http://nem01.altervista.org | \|emesis |XPN (my nr): http://xpn.altervista.orgArticle: 81219
info_ wrote: > Hi, > > I would make a few of suggestions : > > * use an enumeration and traditional "case state is when =>" > construct. This facilitates a lot of things, if only for the > synthesis tool to properly recognize your FSM, but also for > HSL simulation, readability, reliability, optimization etc... I thought the one-hot approach was quite better for performance issues? > * to output the state vector, use a simple decoder (which > will be probably eliminated by synthesis). And maybe you don't > want the one-hot vector vector to come out, but an binary > (more compact) version ? Well, you're just right about that, but for simulation purposes this works just fine! I actually only need three bit-outputs! > * Single-process style is easier to write (imo) and not prone > to the usual errors in combinational processes. > (you're not the first and not the last to get caught) > You can even write Moore style in one process if > you don't want to move your actions in the transitions. Well, I tried doing this, but this gave me a lot of trouble so I took the "VHDL made easy" book and did the "cooking book"-version of a one-hot state machine design. > On my Website, you'll find many FSM examples, FWIW > http://www.alse-fr.com/English/ips.html Thanks, i'll take a look! > I never really liked the "textbook" two-processes style, > and I've seen lots of problems in code written this way... Maybe, Xilinx recommends this too, in their "templates".Article: 81220
Preben Holm wrote: > Hi everyone, > > I try to construct this statemachine as described in VHDL below: > (the machine is supposed to set the hold as soon as the trig-signal is > asserted (initialized only when all signals have been low for a > clock-cycle) and go low when both the read and holdoff signals have been > asserted for some time... > You made the typical mistake --- You didn't clock the inputs. Add one or even two Flip-Flops to every input. vax, 9000Article: 81221
Hi, Hard to say what's wrong without further info... A few wild ideas : * does the Technology View look fine ? * does the post-layout model look fine ? * when you load the design in the simulator, do you see all what you expect ? * sdf file correctly attached and assigned ? * simulation libraries okay ? * How are you vector applied wrt to clock ? * (async) Reset okay ? * Timing resolution 1 ps ? * Stimulus input timings realistic ? * sure you didn't recompile your Vital models with ModelSim XE version ??? (if that's what you're using) * Try & simulate a trivial stuff (just a mult for example) * "no warning no info" may not be a good sign (I'm joking here) And after all, why are you so hot about post-layout simulation if you're reasonably sure of the sanity of your design ? If it's well-behaved, synchronous and all, and no scary synthesis warnings, HDL simulation fine, static timing analysis okay, and you're in a BIG hurry, then I would just keep things moving for now... I hope it helps a tiny bit, Best regards, Bert morpheus wrote: > Hi, > I am trying to design a non-coherent DPSK demodulator as part of my RX > chain of a DSP system in verilog. I have to target my design on a > Vertex-4 development board (for prototyping purposes). Till now, I have > designed my RX chain using two multiplier cores (I and Q multiplied > with their delayed versions) and an adder core ((In)*(In-10) + > (Qn)*(Qn-10)). When I simulate my design at the behavioural level > everything's working fine. I synthesize my design, no warnings/ INFO/ > errors. But, when I do a post-translate simulation, my Q-channel > multiplier stops working. Moreover, when I MAP my design and do a > post-map simulation, the design does not work at all. I get no warnings > or errors in any of the processes > Can anyone help me. If someone decides to be gracious, I can send you > my archived project to look at. I have had this problem in the past and > couldnt solve it. It may be my test-bench (as it is very simple)...but > i just can figure it out. > Any help will be appreciated....i am on a schedule and would like to > keep my job....Lrd have MERCY!!! > Thanks > MORPHEUS >Article: 81222
What is this for? If you are a student and this is part of an assignment I don't want to just give you the answer but that doesn't mean I won't try to help you. Are there any design requirements that need to be followed or met? Style and presentation is very important with VHDL. WIth a programming language like 'C' you can get away with creating compound and nested if statements with different structures and with an optimizing compiler end up with the same result. Early when I was learning VHDL, I noticed that depending on how you structure your code effects the circuit design. In VHDL the compiler tries to implement designs it recognizes ie. state machines. As, someone else pointed out, the way you went about implementing your state machine isn't the expected way. Try implementng using case structure instead of if control structure. Don't forget the differences between case and if statements - if statements are evaluated sequential and case states are evaluated parallel. In VHDL as in C, if you have a large chunk of code and are having trouble with it you should break it up into smaller chunks. Use block and process structures to make your code smaller. It should make your code easier to read and make the compilers job easier. DerekArticle: 81223
Preben wrote:
> info_ wrote:
>
>> Hi,
>>
>> I would make a few of suggestions :
>>
>> * use an enumeration and traditional "case state is when =>"
>> construct. This facilitates a lot of things, if only for the
>> synthesis tool to properly recognize your FSM, but also for
>> HSL simulation, readability, reliability, optimization etc...
>
>
> I thought the one-hot approach was quite better for performance issues?
Quite often it's the case, but using an enumeration does NOT mean
at all giving up one-hot encoding !!! Quite the contrary.
>
>
>> * to output the state vector, use a simple decoder (which
>> will be probably eliminated by synthesis). And maybe you don't
>> want the one-hot vector vector to come out, but an binary
>> (more compact) version ?
>
>
> Well, you're just right about that, but for simulation purposes this
> works just fine!
> I actually only need three bit-outputs!
For simulation, isn't it nicer to see "Writing" in the waveform
viewer rather than "00100" ?
>
>> * Single-process style is easier to write (imo) and not prone
>> to the usual errors in combinational processes.
>> (you're not the first and not the last to get caught)
>> You can even write Moore style in one process if
>> you don't want to move your actions in the transitions.
>
>
> Well, I tried doing this, but this gave me a lot of trouble so I took
> the "VHDL made easy" book and did the "cooking book"-version of a
> one-hot state machine design.
Dave wrote this book a long long time ago, and it was real nice
at that time. Today, the synthesizers are very much smarter,
so it's better to adopt more modern coding styles which are
now well supported by all synthesis tools.
Single process FSM usually means resynchronized Mealy style
as I call it, meaning you have to move the state actions up in
the arriving transitions. (But there is way to code Moore
actions in a single process FSM). That's another way to
desoign, but it's often even easier than Moore style.
See my Quadrature decoder as an example.
> Maybe, Xilinx recommends this too, in their "templates".
I don't want to sound controversial here, but I wouldn't trust
Xilinx as a model of well-written HDL code !
They still deliver this bad code with ISE 6.3.03i (despite my
fixing this bad code more than 3 years ago). It's irritating.
You will appreciate the inout (bidirectional buffer) for the LEDs,
the absence of resynchronization for the async inputs, the initialization
of signals, the absence of reset, the hard tabs in the source file, etc !
(and I won't comment the test bench)
Maybe I misread and it was an example of things NOT to do :-)
There are more experts than good code hanging around...
---------cut & paste from ISE 6.3.03i J2C_vhd Example ----------------------
library IEEE;
use IEEE.std_logic_1164.all; -- defines std_logic types
entity jc2_top is
port (
LEFT : in STD_LOGIC; -- Active-low switch #3 (left)
RIGHT : in STD_LOGIC; -- Active-low switch #0 (right)
STOP : in STD_LOGIC; -- Active-low switch #2
CLK : in STD_LOGIC;
Q : inout STD_LOGIC_VECTOR (3 downto 0) := "0000" -- Active-low LEDs
);
end jc2_top;
architecture jc2_top_arch of jc2_top is
signal DIR: STD_LOGIC := '0'; -- Left=1, Right=0
signal RUN: STD_LOGIC := '0';
begin
process (CLK)
begin
if (CLK'event and CLK='1') then -- CLK rising edge
-- DIR register:
if (RIGHT='0') then
DIR <= '0';
elsif (LEFT='0') then
DIR <= '1';
end if;
-- RUN register:
if (STOP='0') then
RUN <= '0';
elsif (LEFT='0' or RIGHT='0') then
RUN <= '1';
end if;
-- Counter section:
if (RUN='1') then
if (DIR='1') then
Q(3 downto 1) <= Q(2 downto 0); -- Shift lower bits (Left Shift)
Q(0) <= not Q(3); -- Circulate inverted MSB to LSB
else
Q(2 downto 0) <= Q(3 downto 1); -- Shift upper bits (Right Shift)
Q(3) <= not Q(0); -- Circulate inverted LSB to MSB
end if;
end if;
end if;
end process;
end jc2_top_arch;
---------------------------------------
Article: 81224Falk, You could decide to scramble the data and not use 8B10B, but then you would have to be sure your scrambling never violated run length, or DC imbalance issues, and you could live with scrambling multiplying a single error into to more than one. That way you could actually get 3.125 Gbs in V2 Pro, or 10 Gb/s in V2 Pro-X, or 10 Gbs in V4. Austin Falk Brunner wrote: > "news.verizon.net" <res0rsef@verizon.net> schrieb im Newsbeitrag > news:DZK_d.4272$uw6.817@trnddc06... > >>Hi, >>I would like some help from roketio users to find what is the maximum >>realizable freq we can get out of it. I hear that although it supports > > upto > >>3.125Ghz, you can only get only upto 2.5Ghz. Also, can I get any eval > > board > > 3.125 Gbit/s, not GHz. This is the line data rate. Effective data rate is > only 2.5 Gbits/s due to line encoding using 8B/10B encoder (encodes 8 data > bits into 10 data bits to guarantee a constant DC level and transition > density) Virtex4 supports also 64B/66B encoding (which is much more > effcient). > > Regards > Falk > > >
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