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
Symon wrote: > "Duane Clark" <junkmail@junkmail.com> wrote in message > news:bpg6gk02qv@enews2.newsguy.com... > >>Valentin Tihomirov wrote: >> >>>I was always considering VHDL as behaviur/logic (netlist on functional >>>gates) specification language. There are no means to add more detales >>>required at PCB layout abstraction layer. VHDL has no means to describe >>>placement, traces and device packages. I'm I missing missing something? >> >>I think the part you are missing is that Symon wants to replace the >>schematic portion of the PCB layout software. I does not look to me like >>he was talking about replacing the layout portion. Maybe some people put >>layout info on the schematic, but I think most do not. >> >>-- >>My real email is akamail.com@dclark (or something like that). > > > Thanks Duane, you've got it exactly! I agree that the "netlist capture" portion of PCB schematic capture could be more easily done with vhdl or verilog. I like to look at a schematic too, but let's have the machine draw it! Most large digital components have a free vendor-supplied BSDL file that could be converted to an entity with a script. All of the architectures could be null for the purpose of netlist capture. The top_pcb.vhd file would be formatted like a testbench with all of the signal (wire) declarations, entity instances, and port maps. A simulation compile could find unintended shorts and opens, and a viewer could display a schematic for checking wires and entity instances. A script could process top_pcb.vhd to create a netlist compatible with PADS, Allegro etc for layout. The top_pcb.vhd file could be used again when the fpgas code is complete for a board level digital simulation. -- Mike TreselerArticle: 63326
Hi
"Symon" <symon_brewer@hotmail.com> escribió en el mensaje
news:bpg87l$1nmpu4$1@ID-212844.news.uni-berlin.de...
>
> "Ken" <aeu96186_MENOWANTSPAM@yahoo.co.uk> wrote in message
> news:bpg5k3$4a$1@dennis.cc.strath.ac.uk...
> >
> > Hello folks,
> >
> > I am implementing a filter on a -5 Virtex-II part (3000) and the
critical
> > path is one of the longest adder carry chains in the design (28 bits).
> >
> > I have noticed that the minimum period of my design is being clobbered
by
> > the carry chain of the longest adder changing CLB column half-way
through
> > instead of carrying on up the carry chain in the column it started in...
> >
> > So, I would like to be able to put in my VHDL code an RLOC constraint
(or
> > something) that would inform Synplify Pro not to do any clever
> optimisation
> > that will prevent Xilinx ISE 5.2.03i from keeping the carry chain in one
> > column (an old Ray Andraka post has led me to believe this is what is
> > happening).
> >
> > Googling about has yielded some discussions on it but I cannot see
exactly
> > how I would specify this in my VHDL to ensure that the carry chain
remains
> > in one column.
> >
> > Can someone give me some pointers please (ideally a quick code snippet
to
> > demonstrate :-) )?
> >
> > Thanks in advance for your time,
> >
> > Ken
> >
> >
> Ken,
> Have you read the constraints guide in the Xilinx software manuals?
Look
> for the RLOC section. You end up with stuff in your UCF like :-
>
> INST "*un6_burp_cry_0" RLOC = "X6Y4";
> INST "*un6_burp_cry_1" RLOC = "X6Y4";
> INST "*un6_burp_cry_2" RLOC = "X6Y5";
> INST "*un6_burp_cry_3" RLOC = "X6Y5";
> INST "*un6_burp_cry_4" RLOC = "X6Y8";
> etc...
>
> I used the floorplanner to get the names of things I want to RLOC. For
> your problem, you could place the carry chain with floorplanner and send
the
> output to a temporary UCF to give you a start on your RLOC stuff. Hope
that
> makes sense! Read about H_SETs, HU_SETs and U_SETs too.
> good luck, Syms.
>
I prefer the way used in one of Xilinx's TechXclusives to embed RLOC
attributes
directly in VHDL (Relationally Placed Macros). Here's an example of a RPM to
perform a registered a + b, using
the carry chain using the U_SET attribute.
-- begin VHDL code
library ieee;
use ieee.std_logic_1164.all;
library unisim;
use unisim.vcomponents.all;
use work.rlocs.all;
entity a_plus_b_reg is
generic (width: integer := 32; setn: integer := 1);
port (
clock : IN std_logic;
enable : IN std_logic;
a : IN std_logic_vector (width-1 downto 0);
b : IN std_logic_vector (width-1 downto 0);
q : OUT std_logic_vector (width-1 downto 0)
);
end a_plus_b_reg;
architecture rpm_arch of a_plus_b_reg is
attribute INIT: string;
attribute BEL: string;
attribute RLOC: string;
attribute U_SET: string;
signal prexor_int_q: std_logic_vector (width-1 downto 0);
signal int_carry: std_logic_vector (width-1 downto 0);
signal y: std_logic_vector (width-1 downto 0);
begin
int_carry(0) <= '0';
reg: for i in 0 to width-1 generate
attribute U_SET of q_reg: label is "uset" & integer'image(setn);
attribute RLOC of q_reg: label is "X0" & "Y" &
integer'image(integer(i/2));
attribute BEL of q_reg: label is "FF" & belname_xy(i);
begin
q_reg: FDE port map (
D => y(i), CE => enable, C => clock,
Q => q(i));
end generate;
gena: for i in 0 to width-2 generate
attribute INIT of q_lut: label is "6";
attribute U_SET of q_lut: label is "uset" & integer'image(setn);
attribute U_SET of q_mxy: label is "uset" & integer'image(setn);
attribute U_SET of q_xor: label is "uset" & integer'image(setn);
attribute RLOC of q_lut: label is "X0" & "Y" &
integer'image(integer(i/2));
attribute RLOC of q_mxy: label is "X0" & "Y" &
integer'image(integer(i/2));
attribute RLOC of q_xor: label is "X0" & "Y" &
integer'image(integer(i/2));
attribute BEL of q_lut: label is belname_fg(i);
attribute BEL of q_xor: label is "XOR" & belname_fg(i);
begin
q_lut: LUT2
--synthesis off
generic map (INIT => x"6")
--synthesis on
port map (
I1 => b(i), I0 => a(i),
O => prexor_int_q(i) );
q_mxy: MUXCY port map (
DI => a(i), CI => int_carry(i), S => prexor_int_q(i),
O => int_carry(i+1) );
q_xor: XORCY port map (
LI => prexor_int_q(i), CI => int_carry(i),
O => y(i) );
end generate;
genb: for i in width-1 to width-1 generate
attribute INIT of q_lut: label is "6";
attribute U_SET of q_lut: label is "uset" & integer'image(setn);
attribute U_SET of q_xor: label is "uset" & integer'image(setn);
attribute RLOC of q_lut: label is "X0" & "Y" &
integer'image(integer(i/2));
attribute RLOC of q_xor: label is "X0" & "Y" &
integer'image(integer(i/2));
attribute BEL of q_lut: label is belname_fg(i);
attribute BEL of q_xor: label is "XOR" & belname_fg(i);
begin
q_lut: LUT2
--synthesis off
generic map (INIT => x"6")
--synthesis on
port map (
I1 => b(i), I0 => a(i),
O => prexor_int_q(i) );
q_xor: XORCY port map (
LI => prexor_int_q(i), CI => int_carry(i),
O => y(i) );
end generate;
end rpm_arch;
-- end VHDL code
The resulting RPM is a column of 1 x w/2 slices, being w the value assigned
to the width the generic
The setn generic lets you create different U_SET names for different
instances of the entity (if the instances
have no relative positions) or the same U_SET name and applying different
RLOCs to each instance
(if the instances have relative positions).
The rlocs package contains a couple of simple functions to return the
strings "F" or "G"
or the couple "X" or "Y", to differentiate the luts/ffs inside a single
slice. Read the constraints guide
about RLOC, RLOC_ORIGIN and the different kinds of sets you can create. And
the RPM techxcluvise,
of course.
If you prefer the placer to select the absolute positioning of the RPM, then
that's all you need.
If you want total control, then you can select the RPM position attaching an
RLOC_ORIGIN
to the U_SET name in the UCF file.
I've successfully used this entity on the virtex2 architecture & XST. Don't
know how to tell
Synplify Pro to attach those attributes, but it shouldn't be that difficult.
The drawback is your design is no longer portable. You're stuck with Xilinx
parts that use the XY
coordinate system (not all of them). But you can create different versions
for different architectures, of course.
Best regards
Francisco Rodriguez
Article: 63327> we accumualte averages (of cross products of fourier tranforms) What are you going to be using for calculations? If you are planning on using DSP cards, then you don't need to go through PCI. You coud transfer data directly from your A/D card to a DSP card using for example FPDP interface. There is a number of companies who do similar things for radar and sonar. Look at the products by Pentek, ICS, Gage, etc... BTW, I think this discussion drifted away from the FPGA topic, so it probably doesn't belong here... /MikhailArticle: 63328
Jeff Peterson wrote: >> 1. Just capturing the data performing some operation on it, storing >> the results and throwing away the sample > > we accumualte averages (of cross products of fourier tranforms) > So the basic problem is getting 400MB/s of data into memory and processing it, but are you reading 400MB every second, or sampling say once every ten seconds. If it's every second, then you've got a bigger problem because I'd be surprised if you can process it fast enough to get the job done before the next sample comes along. >> >> 2. You might be actually planning to capture to disk 400MB/s for a >> sustained period which has some pretty hairy implications for >> storage capacity. >> > we wont store the raw data, just a very much reduced set. So disk output bandwidth is not going to be a problem, what you are looking for is a way of getting 400MB/s of data into memory for post-processing, correct. Is it possible to break-up the input stream, so for example instead of reading a single stream of 400MB/s, you've five devices reading 80MB/s in parralel? Is the design of the device capturing the data set in stone or can it be "parrallelized" if so it would make the problem much simpler and any solution more scalable and less expensive. -- Nik SimpsonArticle: 63329
Is there a way to conditionally include sections of a UCF file ? I currently have a design with conditional compilation but the I/O ports and ROM contents specified in the UCF file need to differ based on how it's compiled. It'd be nice if there was some sort of #ifdef #else etc... and macro processing..... RobArticle: 63330
"Peter Alfke" <peter@xilinx.com> ha scritto nel messaggio news:3FBBB033.E8A6616A@xilinx.com... > There is an April 2001 TechXclusives "Using leftover multipliers and > BlockRAMs" that describes a surprisingly simple structure for a state > machine with up to 256 states. I never got any feedback on this idea. > There is no software tool, but it's pretty straightforward, and "pencil > and paper" might suffice... > http://support.xilinx.com/xlnx/xweb/xil_tx_home.jsp Just read the article... I like the idea, I'll try to remember the trick next design. Makes medium/big fsm simplicity itself: no routing issues, etc.. very clever. But... too much work for translating to numeric "init" format... Why don't you try to "whisper" a bit at the ears of ISE StateCad mantainers ? Maybe outputting INIT tables from a StateCad graph could boost the use of this particular trick.Article: 63331
stan wrote:
> hi ... I have a question for the experts , I am doing a post mortem of
> my last project , it was a communication processor that was basicly a
> lot of dataflow paths controlled by several rather complex state
> machines ( 100-200 states ) ,
>
Some hardware objects are not efficiently
described as a state machine.
For example, an 8 bit shift register could be
described using a single variable assignment or as a case
of 256 variable states.
Complex sequential logic is easiest for me to
describe using clocked processes with
lots of local variables.
The state machine model is a clocked process
with a single enumerated local variable or signal.
With a state editor as your design entry, this is all you can do.
With synthesis tools, you can have many
local variables of many types in a single clocked process.
You might have a local counter register and a shift register, etc.
One page of clear code replaces pages of circles and arrows.
> The bigger downside here is that since the state machines took longer
> than I expected ( I scheduled 3 weeks of design, project took 6 weeks
> ) my manager has warned me to find another job
I expect that he could not really find anyone faster.
Keep honing your skills, and politely ignore the
"schedule as whip" tactic.
-- Mike Treseler
Article: 63332In article <21Qub.58264$hV.2182491@news2.tin.it>, Antonio Pasini <NOSPAM_pasini.a@tin.it> wrote: >Makes medium/big fsm simplicity itself: no routing issues, etc.. very >clever. >But... too much work for translating to numeric "init" format... Do what I did when I had to implement the Rijndael S-boxes: Write a small program that takes an abstract representation and dumps the init strings. Heck, I may end up having to write one myself, if so, I'd release it. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 63333
Al Clark wrote: > > We have been using Max EPM3032 and EPM3064 devices for several of our > designs. > > The features I like with these devices is as follows: > > 1. Very Cheap - $1.30 for 3032 devices in small quantities > 2. Easy tools with 74 style schematic capture entry. > 3. 3.3V operation with 5V tolerant I/O > > The MAX 3000 is also a power hog which is the main reason I am searching > for alternatives. > > I looked at the Xilinx CoolRunner and CoolRunner 2 parts. Here were my > impressions based from their web site. I would appreciate comments. > > CoolRunner: > > 1. Although they have these parts on their web site, they seem to be > deemphasised. This suggested to me that maybe this line is on the way > out. > > 2. I like the 3.3V supply with the 5V tolerance. > > 3. Power is lower than Altera, prices are higher. > > CoolRunner 2: > > 1. Xilinx wants to sell these parts. > 2. They use 1.8V supplies which is just about the only supply I don't > already need in my design. > 3. They are not 5V tolerant which may or may not be important (but often > is) > 4. They cost more than Altera Max 3000 or CoolRunner. Relative price is a good indicator of CR/CR2 - commonly the newer devices are cheaper, to encourage design migration. Getting an accurate relative price right now is not easy, as vendors are trying to nudge up margins comming out of the slump. Xilinx have a CR2 webseminar inside the next 48 hrs. > What other players or parts should I consider? > > 1. I want schematic entry, reasonably small size in QFP, low power and > low cost. If power is more important than speed, look at Atmel ATF15xx families. They have POF2JED Sw, so you can migrate your Altera design to Atmel, and they are close pinouts to the MAX7032.7064 devices. Other devices are Lattice 4000Z family, and Altera are 'horizon promising' MAX 2 families, but with some caveats : - Currently vaporware - They only claim 90% power reduce, which leaves them well above CR2 and 4000Z levels - Smallest MAX-2 device mentioned is 128 MC, so that's larger than 3032/3064's That's a fairly large chunk of market to ignore.... Lattice's WEB boast's about their Static Icc edge over CR2, but they never mention dynamic Icc (mA/Mhz), so one can conclude they are close, but just loose out on that one :) -jgArticle: 63334
Symon wrote: > Hi Allen, > Thanks for the reply! The tool I use at the moment, ORCAD, has separate > layout and schematic entry bits. So, I agree that layout, i.e. drawing the > traces, makes no sense in VHDL. However, the schematic entry is a pain in > the @rse, after all it's just wiring up components to each other. You end up > typing in lots of attributes anyway, part numbers, value, package size, pcb > footprint. Seems to me that the physical wiring of the parts is perfectly > feasible in HDL, and I can use Perl scripts to speed things along, like I do > with VHDL for my FPGA innards designs. Maybe for some things like a SMPS, a > diagram is very useful, perhaps necessary. However, for connecting a DRAM to > a FPGA, the picture adds very little if anything. Some kind of hybrid is > called for, like we already can do with logic inside FPGAs. > Also, I would expect a HDL to be just as good at pin-swapping / gate > swapping, but, once again, I agree that layout remains inherently graphical. > As you point out the geometry of the traces is vital, and often forms part > of the circuit. You are actually looking for a hybrid - as you say R's and C's do not HDL well. The NETLIST formats of most PCB systems is quite simple, and some import many variants. Better packages allow you to MERGE and CHECK netlists (ie split imports), so you could create a Analog Schematic + Block structure/IC number in Schematic (to keep BOM correct) and then move to HDL for digital interconnects. If the device ( eg U1 TQFP100 ) is already imported via the SCH leg, all your HDL->NET has to do is handle the PinNumber -- NetName collections. That should not be too hard for someone used to scripts. You can also go backwards - eg after PINSWAP, a PCB script can create the PIN - Name list in the HDL format, for manual paste. -jgArticle: 63335
"Jon" <someone@microsoft.com> wrote in message news:bpaned$n7f$1@news2.netvision.net.il... > Hello > > I need help on using serializer and deserializer in an electornic card. > The serializer and deserializer are from national DS90CR287 and DS90CR288 > I'm working with an electronic card that use a serializer of 4 channels > where the input clock is 40Mhz. when the data in the inputs of the > serializer changes in a slow rate the deserializer and FPGA in the other > card can decode the data properly. when the data in the inputs of the > serializer changes in a high rate ( every 50ns ) the data after the > deserializer and the FPGA in the other card can't decode the data. > > The thing is that there are some cards the work and some others that > doesn't > work. > When I look for a diference I found that the 3.3v supply to the serializer > is stable where the card works O.K and when the 3.3v supply has noise the > card doesn't work . It sounds like the PLL is getting too much noise. The datasheet recommends a maximum of 100 mV P-P noise on the VCC. You may want to add a LC filter on the power to the PLL VCC pin and/or run the chip from a low noise linear regulator (LT1963A or equivalent). Make sure all the VCC pins are bypassed and keep the noisy digital lines away from the PLL area. Daniel LangArticle: 63336
"Mike Silva" <snarflemike@yahoo.com> wrote in message = news:20619edc.0311171148.4b9d44f5@posting.google.com... > This Digilent combo package looks to me like an excellent way to learn > FPGAs (but then, I don't know anything yet!): >=20 > http://www.digilentinc.com/Catalog/digilab_2_dio2.html >=20 > Do more experienced eyes see any gotchas with this setup? I realize > the FPGA is bigger than a beginner needs, but the price seems good, > and I gather the part is from a mainstream FPGA family. >=20 > Thanks. I got myself a similar combo but with the dio1 and a couple of the breadboards http://www.digilentinc.com/Catalog/digilab__io1.html http://www.digilentinc.com/Catalog/digilab_breadboard___wire-wrap.html the lack of memory is a bit annoying sometimes Have you had a look at http://www.burched.biz/ http://www.burched.biz/b5xsvp.html AlexArticle: 63337
Using RAM/ROM for a FSM is about as basic as it gets. I remember using that method some 20 years ago about the same time fuse PLDs were starting to appear. Back then fuse ROMs were just about this same size. Peter Alfke wrote: > > There is an April 2001 TechXclusives "Using leftover multipliers and > BlockRAMs" that describes a surprisingly simple structure for a state > machine with up to 256 states. I never got any feedback on this idea. > There is no software tool, but it's pretty straightforward, and "pencil > and paper" might suffice... > http://support.xilinx.com/xlnx/xweb/xil_tx_home.jsp > > Peter Alfke, Xilinx Applications > ============================= > Robert Sefton wrote: > > > > Stan - > > > > I agree with Jonathan that 200 states is nuts. Very error prone and > > probably very difficult to maintain/modify. Were you parsing the > > incoming data stream and making state decisions based on that? If so, a > > programmable communications processor or an embedded processor (like > > Nios for Altera) is a much better and more flexible choice. Some tasks > > just aren't meant to be done in hardware, and parsing data streams is > > one of them. > > > > Nice reward for delivering a working design. I hope you find a way to > > exit that situation. > > > > Robert > > > > "stan" <stanandsue2000@yahooREMOVE.com> wrote in message > > news:3fbb8795.3574357@news.compuserve.com... > > > hi ... I have a question for the experts , I am doing a post mortem of > > > my last project , it was a communication processor that was basicly a > > > lot of dataflow paths controlled by several rather complex state > > > machines ( 100-200 states ) , I did the design by thinking out the > > > control and drawing the state diagrams and then coding them into VHDL > > > for Quartus and into a Stratix .. it worked , after handing over the > > > design to the test department they loaded a board and signed off on > > > the design within a week. My fellow engineers were rather impressed > > > since they knew how complex the control was. > > > > > > The downside here was the state machines became complex and took quite > > > a while to figure out ... then transcibing them into VHDL and also > > > drawing a pretty state chart for documenting the design took a while. > > > Yes I know some say start right with typing VHDL but I find that hard > > > to comceptualize. Since this is a small company big $$ tools are out > > > of the question. > > > > > > So my question ... are there tools out there that can make this > > > process faster ? like drawing the state charts on the screen and > > > outputing VHDL ? or other suggestions ??? again if these are $5-10K > > > tools I won't be getting them in this company so shareware or <$1K > > > tools are preferred even if they lack in some areas. > > > > > > The bigger downside here is that since the state machines took longer > > > than I expected ( I scheduled 3 weeks of design, project took 6 weeks > > > ) my manager has warned me to find another job ( fat chance ) as he > > > has handed in a review requesting a 20% pay cut ... but my real > > > question is about the tools so I may do better next time > > > > > > thanks for any constructive feedback , stan -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 63338
I am not asking for the Nobel prize. I just wonder whether this is a practical, compact, cheap, fast and easy way to build a state machine inside an FPGA... Peter Alfke ============================= rickman wrote: > > Using RAM/ROM for a FSM is about as basic as it gets. I remember using > that method some 20 years ago about the same time fuse PLDs were > starting to appear. Back then fuse ROMs were just about this same > size. > > Peter Alfke wrote: > > > > There is an April 2001 TechXclusives "Using leftover multipliers and > > BlockRAMs" that describes a surprisingly simple structure for a state > > machine with up to 256 states. I never got any feedback on this idea. > > There is no software tool, but it's pretty straightforward, and "pencil > > and paper" might suffice... > > http://support.xilinx.com/xlnx/xweb/xil_tx_home.jsp > > > > Peter Alfke, Xilinx Applications > > ============================= > > Robert Sefton wrote: > > > > > > Stan - > > > > > > I agree with Jonathan that 200 states is nuts. Very error prone and > > > probably very difficult to maintain/modify. Were you parsing the > > > incoming data stream and making state decisions based on that? If so, a > > > programmable communications processor or an embedded processor (like > > > Nios for Altera) is a much better and more flexible choice. Some tasks > > > just aren't meant to be done in hardware, and parsing data streams is > > > one of them. > > > > > > Nice reward for delivering a working design. I hope you find a way to > > > exit that situation. > > > > > > Robert > > > > > > "stan" <stanandsue2000@yahooREMOVE.com> wrote in message > > > news:3fbb8795.3574357@news.compuserve.com... > > > > hi ... I have a question for the experts , I am doing a post mortem of > > > > my last project , it was a communication processor that was basicly a > > > > lot of dataflow paths controlled by several rather complex state > > > > machines ( 100-200 states ) , I did the design by thinking out the > > > > control and drawing the state diagrams and then coding them into VHDL > > > > for Quartus and into a Stratix .. it worked , after handing over the > > > > design to the test department they loaded a board and signed off on > > > > the design within a week. My fellow engineers were rather impressed > > > > since they knew how complex the control was. > > > > > > > > The downside here was the state machines became complex and took quite > > > > a while to figure out ... then transcibing them into VHDL and also > > > > drawing a pretty state chart for documenting the design took a while. > > > > Yes I know some say start right with typing VHDL but I find that hard > > > > to comceptualize. Since this is a small company big $$ tools are out > > > > of the question. > > > > > > > > So my question ... are there tools out there that can make this > > > > process faster ? like drawing the state charts on the screen and > > > > outputing VHDL ? or other suggestions ??? again if these are $5-10K > > > > tools I won't be getting them in this company so shareware or <$1K > > > > tools are preferred even if they lack in some areas. > > > > > > > > The bigger downside here is that since the state machines took longer > > > > than I expected ( I scheduled 3 weeks of design, project took 6 weeks > > > > ) my manager has warned me to find another job ( fat chance ) as he > > > > has handed in a review requesting a 20% pay cut ... but my real > > > > question is about the tools so I may do better next time > > > > > > > > thanks for any constructive feedback , stan > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 63339
Hey Peter - I think it's a great solution, especially with the large number of outputs that can be generated. I also like the multiplier as barrel-shifter. I designed a 32-bit barrel shifter running at 27MHz in an XC4000 part ten years ago and it took up the whole part. Robert "Peter Alfke" <peter@xilinx.com> wrote in message news:3FBBFCC8.E3A34A0D@xilinx.com... > I am not asking for the Nobel prize. I just wonder whether this is a > practical, compact, cheap, fast and easy way to build a state machine > inside an FPGA... > Peter AlfkeArticle: 63340
> ============================= > rickman wrote: > > > > Using RAM/ROM for a FSM is about as basic as it gets. I remember using > > that method some 20 years ago about the same time fuse PLDs were > > starting to appear. Back then fuse ROMs were just about this same Some even included registers, to make single chip state engines ... "Peter Alfke" <peter@xilinx.com> wrote in message news:3FBBFCC8.E3A34A0D@xilinx.com... > I am not asking for the Nobel prize. I just wonder whether this is a > practical, compact, cheap, fast and easy way to build a state machine > inside an FPGA... <paste>> > There is no software tool, but it's pretty straightforward, and "pencil > > > and paper" might suffice... It is a good idea, but the SW tool side could need work to help it take off.. :) It should be FAST, and quite tolerant of state code revisions - with good tools, the state table could be revised without a P&R :) Re the OP of large state machines, some form of nested engines might be a better idea - 200 states is plausible, but they are not likely to have fully random path-links, so a simpler 'umbrella state', with waits from 'task states' could be easier to manage... -jgArticle: 63341
"Nik Simpson" <n_simpson@bellsouth.net> wrote in message news:<vQPub.41$zi3.40@bignews3.bellsouth.net>... > Jeff Peterson wrote: > >> 1. Just capturing the data performing some operation on it, storing > >> the results and throwing away the sample > > > > we accumualte averages (of cross products of fourier tranforms) > > > > So the basic problem is getting 400MB/s of data into memory and processing > it, but are you reading 400MB every second, or sampling say once every ten > seconds. If it's every second, then you've got a bigger problem because I'd > be surprised if you can process it fast enough to get the job done before > the next sample comes along. we will take about 64K samples, then can pause while processing... however all the time we are pausing we are losing data. so we do want to keep the duty cycle up. 50% dudty cyle is not a problem. 5% would be. > > >> > >> 2. You might be actually planning to capture to disk 400MB/s for a > >> sustained period which has some pretty hairy implications for > >> storage capacity. > >> > > we wont store the raw data, just a very much reduced set. > > So disk output bandwidth is not going to be a problem, what you are looking > for is a way of getting 400MB/s of data into memory for post-processing, > correct. Is it possible to break-up the input stream, so for example instead > of reading a single stream of 400MB/s, you've five devices reading 80MB/s in > parralel? Is the design of the device capturing the data set in stone or can > it be "parrallelized" if so it would make the problem much simpler and any > solution more scalable and less expensive. this could work. for example we have considered using 2 x scsi 320 interfaces. might work but its a bit of a kludge, and if we got the two interfaces out of sync we would have a real mess.Article: 63342
"MM" <mbmsv@yahoo.com> wrote in message news:<bpg42l$1o09pi$1@ID-204311.news.uni-berlin.de>... > Do you really need to transfer raw data? Can you do some front-end > processing to bring the speed down? If answers are 'yes' and 'no' > respectively, think of repacking. You can pack 8 bytes into one 64-bit word. > This brings the speed down to 50 MW/s, which should fit into regular 64/66 > PCI. > > > /Mikhail > i dont believe we can reduce the data rate by pre-processing. yes, repacking might allow a 64/66 PCI to accept the data. i worry that we will spend lots of time and money, but the margin will be insufficient for it to actually work. i have heard that some PCI cores are not too efficient. -JeffArticle: 63343
Did you think my comment was a criticism? It clearly is a good way to implement a complex or even not so complex FSM. As long as you won't miss the block RAM I can't see anything wrong. It would be very easy to set up a simple table of present state, next state with outputs. In fact, any time I design a complex FSM, I do that anyway. HDL is nice, but often a table makes the output assignments a lot more clear. Peter Alfke wrote: > > I am not asking for the Nobel prize. I just wonder whether this is a > practical, compact, cheap, fast and easy way to build a state machine > inside an FPGA... > Peter Alfke > ============================= > rickman wrote: > > > > Using RAM/ROM for a FSM is about as basic as it gets. I remember using > > that method some 20 years ago about the same time fuse PLDs were > > starting to appear. Back then fuse ROMs were just about this same > > size. > > > > Peter Alfke wrote: > > > > > > There is an April 2001 TechXclusives "Using leftover multipliers and > > > BlockRAMs" that describes a surprisingly simple structure for a state > > > machine with up to 256 states. I never got any feedback on this idea. > > > There is no software tool, but it's pretty straightforward, and "pencil > > > and paper" might suffice... > > > http://support.xilinx.com/xlnx/xweb/xil_tx_home.jsp > > > > > > Peter Alfke, Xilinx Applications > > > ============================= > > > Robert Sefton wrote: > > > > > > > > Stan - > > > > > > > > I agree with Jonathan that 200 states is nuts. Very error prone and > > > > probably very difficult to maintain/modify. Were you parsing the > > > > incoming data stream and making state decisions based on that? If so, a > > > > programmable communications processor or an embedded processor (like > > > > Nios for Altera) is a much better and more flexible choice. Some tasks > > > > just aren't meant to be done in hardware, and parsing data streams is > > > > one of them. > > > > > > > > Nice reward for delivering a working design. I hope you find a way to > > > > exit that situation. > > > > > > > > Robert > > > > > > > > "stan" <stanandsue2000@yahooREMOVE.com> wrote in message > > > > news:3fbb8795.3574357@news.compuserve.com... > > > > > hi ... I have a question for the experts , I am doing a post mortem of > > > > > my last project , it was a communication processor that was basicly a > > > > > lot of dataflow paths controlled by several rather complex state > > > > > machines ( 100-200 states ) , I did the design by thinking out the > > > > > control and drawing the state diagrams and then coding them into VHDL > > > > > for Quartus and into a Stratix .. it worked , after handing over the > > > > > design to the test department they loaded a board and signed off on > > > > > the design within a week. My fellow engineers were rather impressed > > > > > since they knew how complex the control was. > > > > > > > > > > The downside here was the state machines became complex and took quite > > > > > a while to figure out ... then transcibing them into VHDL and also > > > > > drawing a pretty state chart for documenting the design took a while. > > > > > Yes I know some say start right with typing VHDL but I find that hard > > > > > to comceptualize. Since this is a small company big $$ tools are out > > > > > of the question. > > > > > > > > > > So my question ... are there tools out there that can make this > > > > > process faster ? like drawing the state charts on the screen and > > > > > outputing VHDL ? or other suggestions ??? again if these are $5-10K > > > > > tools I won't be getting them in this company so shareware or <$1K > > > > > tools are preferred even if they lack in some areas. > > > > > > > > > > The bigger downside here is that since the state machines took longer > > > > > than I expected ( I scheduled 3 weeks of design, project took 6 weeks > > > > > ) my manager has warned me to find another job ( fat chance ) as he > > > > > has handed in a review requesting a 20% pay cut ... but my real > > > > > question is about the tools so I may do better next time > > > > > > > > > > thanks for any constructive feedback , stan > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAX -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 63344
"Jeff Peterson" <jbp@cmu.edu> wrote in message
news:369b6e8b.0311191050.44b781b6@posting.google.com...
> we accumualte averages (of cross products of fourier tranforms)
>
Jeff,
I think you need to do the 'we accumualte averages (of cross products of
fourier tranforms)' in your FPGA. That way you dramatically reduce your data
rate down to something sensible. It sounds tricky, but not as tricky as
getting 400M x 8 bits x 50% duty cycle = 1.6 Gbps into a PC and processing
it!
cheers, Syms.
Article: 63345Jeff Peterson wrote: > "Nik Simpson" <n_simpson@bellsouth.net> wrote in message > news:<vQPub.41$zi3.40@bignews3.bellsouth.net>... >> Jeff Peterson wrote: >>>> 1. Just capturing the data performing some operation on it, storing >>>> the results and throwing away the sample >>> >>> we accumualte averages (of cross products of fourier tranforms) >>> >> >> So the basic problem is getting 400MB/s of data into memory and >> processing it, but are you reading 400MB every second, or sampling >> say once every ten seconds. If it's every second, then you've got a >> bigger problem because I'd be surprised if you can process it fast >> enough to get the job done before the next sample comes along. > we will take about 64K samples, then can pause while processing... > however all the time we are pausing we are losing data. so we do > want to > keep the duty cycle up. 50% dudty cyle is not a problem. 5% would be. > From my limited understanding of FFTs the actual processing should be something that could easily be multi-threaded and would see pretty close to linear scalability with additional CPUs, so at the very least an SMP system with at least 2-4 CPUs would help, and assuming it's 64bit floating point then a 64bit CPU like Opteron or Itanium might come in handy. If the idea of multiple data streams is possible (and the synchronization problem can be overcome) then if workload does scale well with CPUs, a cluster of low-cost single CPU systems each processing part of the data stream would be worth looking at as this could be easily scaled, i.e. five systems each handling an 80MB/s stream might be cheaper and faster than one big system trying to crunch 400MB/s. Additionally, if designed this way, then you could add additional systems in order to increase the duty cycle, i.e. 10 systems handing 40MB/s could be relatively cheap and would have roughly 2x the duty cycle of the original 5 systems. > >> >>>> >>>> 2. You might be actually planning to capture to disk 400MB/s for a >>>> sustained period which has some pretty hairy implications for >>>> storage capacity. >>>> >>> we wont store the raw data, just a very much reduced set. >> >> So disk output bandwidth is not going to be a problem, what you are >> looking for is a way of getting 400MB/s of data into memory for >> post-processing, correct. Is it possible to break-up the input >> stream, so for example instead of reading a single stream of >> 400MB/s, you've five devices reading 80MB/s in parralel? Is the >> design of the device capturing the data set in stone or can it be >> "parrallelized" if so it would make the problem much simpler and any >> solution more scalable and less expensive. > this could work. for example we have considered using 2 x scsi 320 > interfaces. might work but its a bit of a kludge, and if we got the > two interfaces out of sync we would have a real mess. Is there any way to insert synch markers in the data stream so that the problem of data streams getting out of sync can be handled? -- Nik SimpsonArticle: 63346
There's nothing conventional about any of this technology. An ex-boss of mine used to say: "The second guy who saw the wheel thought it was obvious". That, by the way, was the only sign of intelligence the guy displayed as far as I know. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 63347
"Simone Winkler" wrote: > Yes - I read the spec of the SDRAM. But in the Xilinx Application Note > there's a design of a SDRAM controller that does a lot of things for me. Consider writing your own SDRAM controller. It isn't all that difficult and you'll know exactly what it is doing each and every step of the way. Besides, you can customize it to deal with your particular needs. Write a little state machine for each operation. They write a separate state machine that would constitute the external command processor. Done deal. Of course, this isn't the only way to do it. You could, for example, implement look-ahead processing to pipeline commands or modify burst access length based on what's coming. The challenge in high-performance SDRAM designs (well, one challenge) is the minimization of wasted clock cycles. Entering and exiting transactions costs clocks and this can be mitigated by using pipelining, among other techniques. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 63348
I think you can do this in HDL, can't you? Place your RLOC's and INIT's in HDL with the right conditionals. I could be wrong. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Robert Finch" <robfinch@sympatico.ca> wrote in message news:HZPub.11926$ZF1.1181323@news20.bellglobal.com... > Is there a way to conditionally include sections of a UCF file ? I currently > have a design with conditional compilation but the I/O ports and ROM > contents specified in the UCF file need to differ based on how it's > compiled. > > It'd be nice if there was some sort of #ifdef #else etc... and macro > processing..... > > Rob > > >Article: 63349
Dave, Same result here (w/Mozilla 1.5). My suggestions: . Try a different browser. . Update java. . Contact your local Altera sales rep for help. Marc Dave Wilson wrote: > Hello all, > > I'm trying to find the max power consumption of an Apex20ke240 with > 3.3v vccio and 1.8v vccint. I've tried the power calculator : > > http://www.altera.com/products/devices/apex/utilities/apx-20kec_calc/apx-20kec_power_calc.jsp > > but it will not let me go past step 1. Has this been discontinued ? > > any suggestions > > Dave
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