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
David T. Wang wrote: > (snip)... I still think that async > design is too hard for a large project, and keeping locally sync > blocks, and just deal with async interface would be a lot easier. > Too hard for a large project? Have a look at http://www.cs.man.ac.uk/amulet/ ... our group have developed the AMULET series of chips; commercially viable asynchronous implementations of ARM cores... a particularly nice feature is the improved EMC because the chip doesn't switch in time to a global clock. As ARM cores are extensively used in GSM cellphone chipsets, this is a pretty desirable feature. It's also good from a low power point of view... for example, roughly 1/3 of the total power dissipated in a DEC Alpha is due to the clock distribution network. I'm currently working on a low power asynchronous DSP core to complement the AMULET processors... there is a lot to be said for keeping locally synchronous blocks with asynchronous interfaces; but there's no need to feed an external clock to them. With locally generated clocks, you can run separate modules at the speed most appropriate for them. IMHO, as we move towards the prediction of a billion transistors on a chip then the idea of a global clock is going to have to go out of the window... partly from a synchronisation viewpoint, and partly because of the power spiking caused by that number of transistors all dancing to the same tune. Mike -- Mike Lewis, mailto:lewism@cs.man.ac.uk -------------------------------------- AMULET Group, University of Manchester http://www.cs.man.ac.uk/~lewism/Article: 15051
Joel Kolstad schrieb:
>
> Does anyone have a clever circuit that can divide an input clock by two and
> a half? We're looking to go from 100MHz down to 40MHz. I've thought of a
> couple of ways to do this, but they all had some asynchronous parts to them
> that required that I could guarantee minimum propagation delays. In a
> 100MHz part I didn't really want to have to guess at the minimum propagation
> delays (neither Xilinx nor Cypress nor Vantis -- vendors whose CPLDs we're
> thinking of implementing this in -- mention their minimum propagation delays
> in the data sheets that I looked at).
>Zipp
> ---Joel Kolstad
Try this :
div_krumm :process (clk_sys )
variable v_zaehler : integer range 0 to 9; --
begin
if (clk_sys'event and clk_sys = '1') then
if reset = '1' then -- Reset synchron
v_zaehler := 0; -- Zaehler auf 0 stellen
clk_xl <= '0' ;
else
v_zaehler := v_zaehler + 1 ;
if v_zaehler > 9 then
v_zaehler := 0 ;
end if ;
if v_zaehler = 2 or v_zaehler = 5 or
v_zaehler = 7 or v_zaehler = 9
then
clk_xl <= '1' ;
else
clk_xl <= '0' ;
end if ;
end if;
end if;
end process div_krux;
No warranty ... try
Article: 15052Rob Why dont you have a look at the Vantis web site, www.vantis.com. There you can download DesignDirect-CPLD which is free of charge. This allows you to do schematic or ABEL entry and then target any CPLD from Vantis from the humble 16V8 PAL upto the 512 macrocell M5 devices. The tool will let you capture the complete design and then estimate what the best device is to use for pin counts, density etc. It is a good way of starting into programmable logic! Peter Trott Vantis In article <19990302151902.13531.00003629@ng-ch1.aol.com>, robert4422@aol.com (Robert4422) wrote: > Hello folks, > > I am trying to get started in programmable logic, but so far having somewhat of > a hard time. I have a simple project sitting in my digital circuit emulator > program, and I would like to realize it using some kind of programmable logic > device. Actually, I had been planning to realize the design in discrete 74xx > TTL's (it's that simple--just a 10-bit counter, some AND gates, some flip > flops, and some NAND gates), but I thought this might be a good time to get > into the world of programmable logic devices. So far, however, I'm having a > lot of trouble sorting through all the different kinds of devices that are > available, and was wondering if anyone here could help me out. > > Specifically, perhaps someone could help me with the following questions: > > 1. What kind of programmable devices should I be looking into to implement the > design mentioned above? I assume the presence of flip-flops and an n-bit > counter is a little beyond the level of PALs and GALs, but perhaps I'm wrong? > Is FPGA what I need/want, or something else entirely? > > 2. Moreover, can someone give a brief description of the differences between > the major families of programmable devices? e.g., PAL vs. GAL vs FPGA etc. > (if there's a FAQ or other reference that does this, please just point me to > it.) > > 3. Which families of devices have TTL-level inputs/outputs? > > 4. What are some good introductory reference materials? Books, websites, etc. > > Thank you for your time and help in getting a beginner started! > > Rob > > VHDL > -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 15053
In article <36DE3D89.B3B630EC@kom.auc.dk>, Lasse Langwadt Christensen <fuz@kom.auc.dk> wrote: > alex_schreiber@my-dejanews.com wrote: > > > > Hi, > > > snip > > > > In traditional (synchronous) design techniques you always have > > the problems of wiring delays. This becomes even more problematic > > when you are moving towards smaller gate length (Very Deep SubMicron). > > The transistor switching time becomes less important in comparison > > to the wire delay. Additionally the amount of gates per area becomes > > higher as well, which leads to longer clock nets as well. > > smaller chips leading to longer nets, that doesn't make sense ? The die area keeps the same, just the transistor and interconnect geometries (not in the same rate) are becoming smaller. This means, a larger amount of transistors can be implemented on the same area. Moving towards smaller technologies does not mean 'smaller' chips. If the attributes 'small' and 'large' are based on the functionality, even the contrary is correct: more transistors - more functionality - 'larger' chips. > > > > > In a synchronous system you need to guarantee that there is not too > > much skew between the each clock input of the same clock net. The > > effort to achieve this becomes higher and higher. > > > > Exactly here is the advantage of self-timed logic. Because a > > proceeding action is triggered by the completion of the previous > > one, you do not have such distribution problems. > > won't you have more or less the same problems, just on the signals > timing instead of the clock? IMO no, because these protocol signals are connecting to a lower number of inputs as the clock of a synchronous system (strict definition: each flip-flop of the system is clocked by the same clock). So the capacitive and resistive load is smaller and the signal can be distributed faster. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 15054
Hi ,
We at Mysticom have developed a 10/100 Ethrnet Core .
For more information look at our website : http://www.mysticom.com
Regards ,
Lior
Charles F. Shelor wrote in message ...
>Howdy,
>
>I am involved in a make/buy decision to develop or purchase a VHDL
>based Fast Ethernet core for use in an FPGA and then migrate to
>an ASIC. I am interested in any opinions, recommendations, etc
>from anyone who has purchased/used a Fast Ethernet core in an
>FPGA/ASIC. Core vendors are welcomed to respond as well.
>
>Thanks,
>
>Charles
>
>charles@efficient.com
>
>Charles F. Shelor
>Efficient Networks
>"DSL for the Masses"
>972 991 3884
>
>--
>Charles Shelor (formerly SHELOR ENGINEERING
>Sr ASIC Designer VHDL Training and models)
>Efficient Networks, Inc http://www.efficient.com
>972 991 3884 mailto:charles@efficient.com
Article: 15055
What you appear to be describing is equivalent to decoding the
output(s) of a counter for a particular value, and using that decode
to reset the counter.
This will work if
a) the decode is glitchless, and
b) the propagation delay from any counter Q to the counter RST input
is longer than the counter's RST(min) pulse width
a) is achieved by syncing the decode with the counter clock. In an
FPGA, where routing delays could be just about anything, b) needs to
be done the same way.
BTW, the old 4000 CMOS logic was designed to work in this way, by
careful internal design. In most cases, you could safely connect a
counter output back to RST, to create a mod-x counter.
>Assume you have a state machine that has some "interesting" state
>encoding... say the reset state encodes to 1010, and then the state machine
>always steps to a state encoded by 0101. This state machine has an
>asynchronous reset input, which comes from a pin on a CPLD or FPGA. The
>clock to this synchronous state machine also comes from a pin.
>
>Isn't a completely asynchronous reset input just asking for trouble? While
>reset is active, the state machine is sitting at 1010. If I now assume that
>reset goes inactive just a split (nano)-second before the active clock edge,
>I don't have any guarantees at all that some of the state encoding bits are
>going to transition to their expected new values, whereas some won't
>transition at all, correct?
>
>If this is really an issue, it would appear that the correct way to apply an
>asynchronous reset is to first run it through a synchronizer before applying
>it to the asynchronous reset input of the state machine.
--
Peter.
Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.
Article: 15056Lasse Langwadt Christensen wrote: > how about using the divided clock to enable/disable the edges? > > count three rising edges, invert clk_out, count three > falling edges invert clk_out..... > > increment counter here:(on rising when clk_out = 1, on falling when > clk_out = 0) > | | | | | | | | | | > v v v v v v v v v v > _ _ _ _ _ _ _ _ _ > clk _| |_| |_| |_| |_| |_| |_| |_| |_| | > ________ _________ > clk_out \_________/ \____ > > is it possible ? > > --L2C > --___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_---- > Lasse Langwadt Christensen, MSEE (to be in 1999) > Aalborg University, Department of communication tech. > Applied Signal Processing and Implementation (ASPI) > http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.org Yes, but the design you describe divides by 5 - Joel wants to divide by 2.5! Catalin BaetoniuArticle: 15057
Another reason foundation is broken. In viewlogic, you just create a symbol for each design then put them The symbols) in a top level schematic. Where there are connections between the macros, you would want to remove the IO macros. You might want to move the IOs to the top level, but in viewlogic it isn't mandatory. Now for foundation...I've had similar problems in the past. AFAIK, foundation still requires macros to be one page only. The easiest approach might be to save each page as a separate schematic and then make each into a macro. Instantantiate those macros on a single page to create a hierarchical macro, then call that macro in your new top level design. Dan Kuechle wrote: > I want to combine 3 xilinx designs (4005xl's) into a single 4013xl part. > The 3 designs are all done in foundation schematic entry, and are "flat". > Each design is about 5 pages of schematics. > Can I do a hierarchial schematic for this large design by creating a macro > for each of the 3 small designs and then connecting them all togeather on > a top level schematic? This would require creating a macro for each > of the small designs from its multi-page schematic. I have been able to > create a macro from "the current schematic page", but have not been able > to create a macro from a multi-page schematic (or add a schematic page > to a macro). Can someone help? > > Thanks > Dan -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 15058
Am I correct in saying that the Virtex chips are now run-time reconfigurable, in a simialr manner to the 6000 series? Cheers for any info DarylArticle: 15059
Sorry, have found all the info out I need on the xilinx site. I'll wake up sometime today DAryl Daryl Bradley wrote: > Am I correct in saying that the Virtex chips are now run-time > reconfigurable, in a simialr manner to the 6000 series? > > Cheers for any info > > Daryl -- Bio-Inspired Architectures Department of Electronics University of York, UK 01904 432379 (office) http://www-users.york.ac.uk/~dwb105Article: 15060
Joel Kolstad wrote:
> Catalin wrote in message <36DDB822.DD4263E3@spam.com>...
> >The Vantis CPLD family MACH5 has FFs that can toggle on both clock edges
> (and
> >with two clock enables, one for each edge). If you use a divide by 5 binary
> >counter that counts on both 100MHz clock edges you will get a 40MHz output
> (with
> >40%-60% duty factor on Q1 and 20%-80% on Q2). Since this solution is
> completely
> >synchronous you do not have minimum delay problems.
>
> This requires you to buy a device with a "counting" frequency of 200MHz
> though, doesn't it?
>
> BTW, for other people who have offered suggestions -- thanks. Since there's
> been some confusion as to what the requirements of the output are, I'll
> explain further. The 40MHz output is a pixel clock to a frame grabber. The
> frame grabber has a PLL on-board, so it wants a 40MHz input that has
> relatively low jitter from one cycle to the next (the PLL happens to be a
> Cypress CY7C992 RoboClock). The output doesn't have to be precisely 40MHz;
> something within +5%/-10% would be OK as well.
>
> ---Joel Kolstad
Before exploring further any digital solution to your problem you must be aware
of the following limitation. If your 100MHz clock does not have 50% symmetry
(and no clock has absolute symmetry) your 40MHz output will always have jitter.
For example, if your input clock is 4ns high and 6 ns low, the output clock will
have alternating periods of 24ns and 26ns, no matter how clever your design is.
If your frame grabber PLL cannot tolerate this kind of input then I think your
best bet is an external PLL clock (like the 2$ Cypress CY2071A). If the
alternating period jitter is OK and you do not need 50% symmetry for the 40MHz
(you cannot get anything better than 40%-60% anyway) the simplest solution I
think is the following:
entity div25 is
port(CLK100: in STD_LOGIC;
RESET: in STD_LOGIC;
CLK40: out STD_LOGIC; -- 100MHz div 2.5 (40MHz 40-60%)
CLK20: out STD_LOGIC); -- 100MHz div 5 (20MHz 50-50%)
end div25;
architecture div25_arch of div25 is
signal CLK:STD_LOGIC;
signal Q:STD_LOGIC_VECTOR(2 downto 0);
begin
CLK<=CLK100 xor Q(2) when Q(1 downto 0)="11" else
not CLK100 xor Q(2);
process(CLK,RESET)
begin
if RESET='1' then
Q<=(others=>'0');
elsif rising_edge(CLK) then
if Q(1 downto 0)="00" then
Q(2)<=not Q(2);
end if;
Q(1)<=Q(0);
Q(0)<=not Q(1);
end if;
end process;
CLK40<=Q(1);
CLK20<=Q(2);
end div25_arch;
This takes just 1.5 XC4000XL CLBs (you cannot make it smaller than that!) and it
runs at 256MHz in an XC4013XLA-07 so speed should not be a problem even with
slower and cheaper parts.
Since the combinatorial clock CLK goes to two CLBs you must ensure that the net
delay is equal for both CLBs or use a global clock buffer. This way you will not
have any problems with minimum delays.
Catalin Baetoniu
Article: 15061On Tue, 02 Mar 1999 17:38:52 -0500, Todd Kline <todd@wgate.com> wrote: >I apologize for being slightly off subject, but have any of the members >of this group worked with any "fast-turn" ASIC vendors? We are looking >for fab times under a month. We have worked with Chipexpress in the >past, but Chipexpress doesn't have any processor core licenses and the >ASIC we are doing needs an embedded processor. I presume from your statement that you have not yet selected your processor, as it would seem your requirement centres around the existence of any core, rather than specifics? So....Why not license your own core, and then put your ASIC out to tender, rather than up for ransom? Try www.arccores.com Cheers Stuart Paint me biased as the company I work for represents ARC in the UK For Email remove "NOSPAM" from the addressArticle: 15062
Thanks to Barbara Walters' long commercials, here is the "ultimate" purely digital solution in two XC4000XL CLBs: Build a rising edge-triggered divide-by 5 counter out of three flip-flops and LUTs. There are 224 different ways to do this. Pick one where one of the flip-flops is High only for two consecutive clock periods. Use the fourth LUT as a latch with three inputs: its own output, the flip-flop, and the clock. Program the output of this LUT-latch such that it is High when (ff) OR ( lut AND clock ). In other words: the output goes High when the ff goes High, but then stays High, even after ff has gone Low, until the next falling clock edge. That output is your 40 MHz low-jitter signal. It is guaranteed to be glitch-free. Two remaining problems: Your simulator may balk at this combinatorial feedback, and you will of course see the effect of a non-symmetrical input clock also at the output. Peter Alfke, Xilinx ApplicationsArticle: 15063
Does anyone know if it is possible to use a Xchecker probe together with a Virtex ? If yes, can I use a 5-Voltage probe with VCC=+5V at the probe and the VCCo=+3.3V at the I/O banks? If yes, Is the Xchecker probe interface to a Virtex the same as to a XC4000? Thanks. StefanArticle: 15064
Actually, I'd love to use the ARC core. It is hands down my first choice for a soft core. Unfortunately, my boss balks at the up-front license fee of soft cores, even the "relatively" low fee for the ARC. We are a start-up, so cash flow management is extremely important. Thanks, Todd > > I presume from your statement that you have not yet selected your > processor, as it would seem your requirement centres around the > existence of any core, rather than specifics? > > So....Why not license your own core, and then put your ASIC out to > tender, rather than up for ransom? > > Try www.arccores.com > > Cheers > StuartArticle: 15065
Hi, I've got a project consisting of mostly 74xxx series ICs which I want to build, to make it easier an nice I wonder if I could use programmable logic and eliminate the number of ICs required. Could you please tell me how to Programme these devices - PALs,PEELs,GALs etc how easy it is (Do they accept JEDECs file formats) and also a very cheap programmer (or how to make one) as I am only a student and can't afford these nice expensive programmers. Many thanks NeilArticle: 15066
The 8th International HDL Conference & Exhibition April 6th - 9th Santa Clara Convention Center Santa Clara, CA. Advanced and introductory topics on Verilog and VHDL.design, and Innovative HDL Techniques for System-on-Chip (SoC) design. This conference and exhibition will feature papers, tutorials, panel sessions, keynote speakers, and 50 EDA exhibitors. Some of the topics covered include Intellectual Property, Timing Issues, Synthesis, Verification, and Language Specifics. NEW AT HDL CON' 99 * Single session pass registration. * Register in advance and be automatically entered into a drawing to win a Canon ELPH Camera! * Register 2 people and receive the third registrant for FREE! * Register for only one tutorial session and see the exhibits as part of the package. * Location, Santa Clara Convention Center... It's close to work or home! Swing by for a 1/2 day of sessions, networking, exhibits, and speak to vendors in one location! Stop by the web site for more information and on-line registration. http://www.hdlcon.org Mark your calendars and sign-up now (Limited seating capacity). Sign up in advance for the full conference $300 (or $400 at the door). For more information contact the HDL Conference office at 5305 Spine Road, Suite A Boulder, CO 80301 Tel: 303-530-4562 Fax: 303-530-4334 e-mail: info@hdlcon.orgArticle: 15067
Hi! In the 1k and 2k Lattice ispLSI data sheets, I read the term "XOR adjacent path". Wath is it exactly? Thanks... LuigiArticle: 15068
Mr Tisdale wrote: > > Hi, > > I've got a project consisting of mostly 74xxx series ICs which I want to > build, to make it easier an nice I wonder if I could use programmable logic > and eliminate the number of ICs required. Could you please tell me how to > Programme these devices - PALs,PEELs,GALs etc how easy it is (Do they accept > JEDECs file formats) and also a very cheap programmer (or how to make one) > as I am only a student and can't afford these nice expensive programmers. Take a look at www.altera.com. Their Max+plus II software comes in a student edition (a 6 month trial with a reduced number of synthesis targets). It has function generators for the 74xxx series and is relatively easy to use. Maybe you could convince your school/university to buy an evaluation board for you, altera makes one that costs about $150 as far as I remember, but AFAIK they don't sell them to private persons. -- Brian Pedersen, DSP Student _/ _/_/_/ _/_/_/ _/ Applied Signal Processing and Implementation _/_/ _/ _/ _/ _/ Department of Communication Technology _/ _/ _/_/_/ _/_/_/ _/ Aalborg University, Denmark _/_/_/_/ _/ _/ _/ URL: http://www.danbbs.dk/~kibria/brian/ _/ _/ _/_/_/ _/ _/Article: 15069
I was able to use the xchecker with a virtex part ... the only trick was to connect the Vcc pin on the xchecker cable to a +5V source on our board ... if you don't have 5V on your board Xilinx sells a small adapter which steps up the 3.3V on your board to the 5V required by the cable (or you could easily built your own) markArticle: 15070
Mike Lewis (lewism@cs.man.ac.uk) wrote: : David T. Wang wrote: : > : (snip)... I still think that async : > design is too hard for a large project, and keeping locally sync : > blocks, and just deal with async interface would be a lot easier. : Too hard for a large project? Have a look at : http://www.cs.man.ac.uk/amulet/ ... our group have developed the AMULET : series of chips; commercially viable asynchronous implementations of ARM : cores... a particularly nice feature is the improved EMC because the : chip doesn't switch in time to a global clock. As ARM cores are : extensively used in GSM cellphone chipsets, this is a pretty desirable : feature. It's also good from a low power point of view... for example, : roughly 1/3 of the total power dissipated in a DEC Alpha is due to the : clock distribution network. : I'm currently working on a low power asynchronous DSP core to complement : the AMULET processors... there is a lot to be said for keeping locally : synchronous blocks with asynchronous interfaces; but there's no need to : feed an external clock to them. With locally generated clocks, you can : run separate modules at the speed most appropriate for them. Nothing wrong with that. Still locally sychronous, and globally async. Once you get to that stage, where the clock comes from, and what speed it runs is entirely irrelevant. : IMHO, as we move towards the prediction of a billion transistors on a : chip then the idea of a global clock is going to have to go out of the : window... partly from a synchronisation viewpoint, and partly because of : the power spiking caused by that number of transistors all dancing to : the same tune. I think we're agreeing, but not claiming to be so. As distributing a global synchronizing signal becomes harder and harder, async's difficulties stays constant. :) : Mike : -- : Mike Lewis, mailto:lewism@cs.man.ac.uk : -------------------------------------- : AMULET Group, University of Manchester : http://www.cs.man.ac.uk/~lewism/ -- No SPAM or email wholly without substance please davewang@cslab.kecl.ntt.co.jp.I.like.green.eggs.and.ham,not.spam All statements are personal opinions Not speaking for NTT or University of Maryland Kyoto, Japan.Article: 15071
W've been looking at using FPGAs form Dynachip. I have a few questions: 1. Are their timing info correct or just marketing hype? 2. Is is true what they say that the routing delays are predictable? 3. How are their back end tools? 4. How's their tech support? 5. And finally will they be there in the long run?Article: 15072
Hi! Thanks for the reply. Actually I am describing the circuit from a high level environment that I developed. It is a lot easier for me to use a single LFSR. Using multiple LFSRs needs extra development of the my tools to generate the proper layout ( I am generating placement information myself from a high level programming environment which generates EDIF netlist). That's why I wanted to use high fanout signals. May be I'll do an extra effort! - use multiple LFSRs-.Article: 15073
Hi! Thanks for the reply. Actually I am describing the circuit from a high level environment that I developed. It is a lot easier for me to use a single LFSR. Using multiple LFSRs needs extra development of the my tools to generate the proper layout ( I am generating placement information myself from a high level programming environment which generates EDIF netlist). That's why I wanted to use high fanout signals. May be I'll do an extra effort! - use multiple LFSRs-.Article: 15074
Hi! Thanks for the reply. Actually I am describing the circuit from a high level environment that I developed. It is a lot easier for me to use a single LFSR. Using multiple LFSRs needs extra development of the my tools to generate the proper layout ( I am generating placement information myself from a high level programming environment which generates EDIF netlist). That's why I wanted to use high fanout signals. May be I'll do an extra effort! - use multiple LFSRs-.
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