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 Jan 27, 1:02=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > I'm working in a Spartan 3 with XST 10.1. =A0I'm trying to divide down a > 32 MHz clock to make a 128 kHz clock on the DCLK output pin. I'm > implementing it with a downcounter that (resets itself and toggles the > pin) when it gets to zero. Nothing tricky there so far. > > Then I synthesize the whole thing and, just for fun, go spelunking in > the FPGA editor to see how it built the logic. =A0As expected, it's a 7 > bit downcounter, implemented using the carry chain. =A0And yet the > zero-detection logic, rather than using the perfectly good carry-out > signal from the decrement chain, is being implemented with an 8 input > NOR, split across several slices. > > Of course, this still works. =A0At 32 MHz I could ship each individual > bit to Taiwan on a barge and wait for the answer by carrier pidgeon and > it would still work. =A0But it seems like an odd choice to have made. =A0= By > my guesstimations it's both larger and slower than using the carry-out. > > Anyone care to speculate why? > -- Rob > > ---------------------------------------------------------------------- > > MAKE_DC_DC: process(clk) > > variable toggle =A0 =A0 : std_logic :=3D '0'; > > constant TICKS_CYC =A0: integer :=3D 32_000_000 / 128_000; > constant TICKS_HALF : integer :=3D TICKS_CYC / 2; > > variable divider =A0 =A0: integer > =A0 =A0 range 0 to TICKS_HALF-1 :=3D TICKS_HALF-1; > > begin > =A0 =A0 if rising_edge(clk) then > =A0 =A0 =A0 =A0 DCLK =A0 =A0<=3D toggle; > > =A0 =A0 =A0 =A0 if ( (divider - 1) < 0 ) then > =A0 =A0 =A0 =A0 =A0 =A0 divider :=3D (TICKS_HALF-1); > =A0 =A0 =A0 =A0 =A0 =A0 toggle =A0:=3D not toggle; > > =A0 =A0 =A0 =A0 else > =A0 =A0 =A0 =A0 =A0 =A0 divider :=3D divider - 1; > =A0 =A0 =A0 =A0 end if; > =A0 =A0 end if; > end process MAKE_DC_DC; > > ---------------------------------------------------------------------- > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order Rob, you need to divide 32 MHz by 250, whichis not an integer power of 2, and it takes an 8-bit counter. There are many different ways to do this efficiently. Peter AlfkeArticle: 137701
On Wed, 28 Jan 2009 00:54:36 +0100, "Jan Bruns" <testzugang_janbruns@arcor.de> wrote: > >"Rob Gaddi": >> Of course, this still works. At 32 MHz I could ship each individual >> bit to Taiwan on a barge and wait for the answer by carrier pidgeon and >> it would still work. But it seems like an odd choice to have made. By >> my guesstimations it's both larger and slower than using the carry-out. > >Really? > >> variable divider : integer >> range 0 to TICKS_HALF-1 := TICKS_HALF-1; > >> ... > >> if ( (divider - 1) < 0 ) then >> divider := (TICKS_HALF-1); > > >When, per definition, is a positive varibale decremented by one >less than zero? Maybe if the decrement leads to a high MSB. just >like the set/reset in the example does? > >I'm really not sure about this (don't have the money to buy >expensive standard specifications, and also prefer verilog). An integer is a signed entity so if you're decrementing it, the first time n-1 becomes less than zero is when n == 0. I think the idea was that divider reg would get a decrement operator generator by carry chain and then the final carry being set would indicate n-1 becoming negative. It's a cute idea but synthesizer probably is not smart enough to do operator sharing at the output of the decrementer and instead builds a zero decoder at the output of the register. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 137702
On Tue, 27 Jan 2009 06:00:45 -0800 (PST), Gabor <gabor@alacron.com> wrote: >On Jan 27, 3:50 am, secure...@gmail.com wrote: >> Hi, >> >> I have to make a PCB using BGA pinout for FPGA. >> >> What brand of software do you use ? >> >> Place Route manually or automatically ? >> >> Which plans to use and how ? >> >> For the width of the tracks ? >> >For a hobby budget you could look at one of the on-line >do-it-yourself software / fab packages like PCB123. I >have used this for simple 2 and 4-layer boards. They >list the design rules on their site and you can download >the software there, too. PCB123 are great, but unfortunately their design rules eliminate them for BGAs (maybe 48-pin memory BGAs you can route on the top layer are OK) Their parent company will make finer rule boards from other systems though. It may be worth looking at http://www.freepcb.com/ I tried this last year and it looked OK for a 676 pin 1mm BGA. (If you cross-check the Gerber output carefully!) I didn't get as far as finishing the board though. - BrianArticle: 137703
Peter Alfke wrote:
> Rob, you need to divide 32 MHz by 250, whichis not an integer power of
> 2, and it takes an 8-bit counter.
He did use 25:
constant TICKS_CYC : integer := 32_000_000 / 128_000;
The question is synthesis of the count down to zero.
I expect that the code synthesizes ok.
However, carry chains vs plain LUTs is up to the default constraints.
-- Mike Treseler
Article: 137704LittleAlex wrote: > > Myself, I use OrCAD and PADs. This pair is common in the village I > live in. > Many years ago I used some old PADs and then OrCAD. OrCAD's schematics capture is great and the board layout is OK. But I didn't like the process very much and hired somebody else to do a complex board. He used Protel - now Altium Designer. After I used it a little to do minor changes to his design, I liked it so much that I do most boards myself once again. In particular the "fan-out" feature is great. It automates routing the BGA pads to the outside world. Then it is a very good idea to route by hand. Even the best autorouters make ugly boards. My advice is to use Altium Designer if you can afford it. -Alex.Article: 137705
On Jan 27, 7:08=A0pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Tue, 27 Jan 2009 09:35:19 -0800 (PST), jleslie48 > > <j...@jonathanleslie.com> wrote: > >here's the source to the fifo: > >http://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/VHDL/bbfifo_16x8.vhd > > >and I "think" this is the storage: > > > -- SRL16E data storage > > > =A0data_width_loop: for i in 0 to 7 generate > > =A0-- > > =A0attribute INIT : string; > > =A0attribute INIT of data_srl : label is "0000"; > > =A0-- > > =A0begin > >so here are the quickie questions: > > ... my answer I think would be: this is WAY too low-level to be dealing > with unless you really need it for performance or you are down to your > last few LUTs... > > This is the assembly language of hardware. > > >1) what's a LUT? > > ... basic unit of logic - typically implements a boolean function of 4 > variables. Xilinx has a neat hack (SRL16) using one LUT as a 16-bit > shift register. > > >2) what do you use the reserved words ATTRIBUTE and LABEL ? > > When you need to force the tools to do something very specific; usually > but not always, a low level detail. > > >3) what is that GENERIC MAP thing and what does(INIT =3D> X"0000") > >mean ? > > Generics are generally useful; inside an entity, treat them as constants > and base as much of a design off them as you dare. Outside, use a > generic map to replace them with real values to parameterise your > design. > > >4) INIT is the variable name right not a reserved/library word? > > yes - actually the generic not the variable.>5) what about STRING? > > A subtype of ARRAY OF CHAR - defined in the STD library I think > > >6) =A0but where does data_out take on the > > =A0value of the character to be sent? =A0 > > Part of the SRL16 hack's internal magic. > > Seriously; if you can treat this "bbfifo.vhd" as a black box, go ahead > and use it. Otherwise stick to behavioural level VHDL coding until you > find something you really can't do that way. > > Life's too short. If you have to get involved at this level I agree with > Jonathan- you're in too deep. > > But you know how to build a counter. I suspect you know how to use it to > address an array and read and write its contents. Do you need to spend > time on the innards of a FIFO? > > If you can keep it behavioural, and let the synthesis tool do (99% of) > this low level detail for you, I think you have a chance. > > - Brian ~Seriously; if you can treat this "bbfifo.vhd" as a black box, go ahead ~ and use it. you're the second person today to tell me that. That's actually a bit of a comfort. So any throttling of the 16 bit buffer will have to be done outside of the bbfifo.vhd. I can live with that. Thanks. so my buffering of scheduled messages will have to live outside the confines of the uart package. Well that concludes another 14 hr day. back again at it tomorrow.Article: 137706
On Tue, 27 Jan 2009 13:02:38 -0800, Rob Gaddi wrote: > I'm working in a Spartan 3 with XST 10.1. I'm trying to divide down a > 32 MHz clock to make a 128 kHz clock on the DCLK output pin. I'm > implementing it with a downcounter that (resets itself and toggles the > pin) when it gets to zero. Nothing tricky there so far. > > Then I synthesize the whole thing and, just for fun, go spelunking in > the FPGA editor to see how it built the logic. As expected, it's a 7 > bit downcounter, implemented using the carry chain. And yet the > zero-detection logic, rather than using the perfectly good carry-out > signal from the decrement chain, is being implemented with an 8 input > NOR, split across several slices. > > Of course, this still works. At 32 MHz I could ship each individual bit > to Taiwan on a barge and wait for the answer by carrier pidgeon and it > would still work. But it seems like an odd choice to have made. By my > guesstimations it's both larger and slower than using the carry-out. > > Anyone care to speculate why? > -- Rob > > ---------------------------------------------------------------------- > > MAKE_DC_DC: process(clk) > > variable toggle : std_logic := '0'; > > constant TICKS_CYC : integer := 32_000_000 / 128_000; constant > TICKS_HALF : integer := TICKS_CYC / 2; > > variable divider : integer > range 0 to TICKS_HALF-1 := TICKS_HALF-1; > > begin > if rising_edge(clk) then > DCLK <= toggle; > > if ( (divider - 1) < 0 ) then > divider := (TICKS_HALF-1); > toggle := not toggle; > > else > divider := divider - 1; > end if; > end if; > end process MAKE_DC_DC; > > ---------------------------------------------------------------------- I always add 1 bit to my counters and the use the MSB to do the reset, for example if I wanted to divide by 256 I'd do, reg [8:0] cntr; always@(posedge clk) begin if(sync_rst || cntr[8]) begin cntr <= 1; end else begin cntr <= cntr + 1; end This forces the synthesizer to use the sync set/reset inputs and the reset path will only have 1 LUT delay in it.Article: 137707
Hi Rob Gaddi > Same way you manually do 600 of anything else, one at a time. ... :-) ... I imagine that it is the best. Thnaks. Kappa.Article: 137708
Hi Rick, > Your initial post seemed to be asking about basic things like trace > width. =A0If you have designed boards before then I would expect that > you either know a bit about choosing a trace width or just winged it > and got lucky on your other boards. =A0Either way, there are places > where you can ask advice. =A0This is a good start, but some other news > groups might be better, such as sci.electronics.design and > sci.electronics.cad. =A0Once you choose a layout package there should be > support forums where you can ask for help, both specific to that > package and general advice on board design. I will try to ask in these groups. I asked here, because surely you are using FPGA and maybe someone builds PCB. > There is a lot more to PCB design than just routing wires. =A0You should > treat this as a learning experience and read as much as you can so > that you can learn from the mistakes of others. I keep in mind ... Thanks. Kappa.Article: 137709
Hi LittleAlex > Myself, I use OrCAD and PADs. =A0This pair is common in the village I > live in. ... :-) ... > The part you will -really- need help with is the FPGA pin-out. =A0Lots > of different approaches, but for your very 1st board I suggest the > trial & error method so you can appreciate the complexity. Thanks. Kappa.Article: 137710
Hi Brian Drummond > It may be worth looking athttp://www.freepcb.com/ > I tried this last year and it looked OK for a 676 pin 1mm BGA. > (If you cross-check the Gerber output carefully!) I didn't get as far as > finishing the board though. But with CS486, the pins are very close, 0.8 mm ... Kappa.Article: 137711
Hi Alex, > Even the best autorouters make ugly boards. It seems that all producers of software pcb, pointing to this "Autoroute" are all lies ? > My advice is to use Altium Designer if you can afford it. I see what it is. Thnaks. Kappa.Article: 137712
Jonathan Bromley wrote:
> you know I'm a strong supporter of the design
> style you advocate, although I'm less persuaded
> than you are by the benefits of parameterless
> procedures.
I use procedures to fix the process template
and otherwise to avoid cut and paste errors
on repeated blocks of code.
> However, that doesn't affect the
> key point I made in an earlier post:
> once you have encapsulated some functionality
> in an HDL process, your ability to do any form
> of sequential/procedural composition is gone.
Aye, theres the rub.
All else is pesky wires.
I make processes as large as I can tolerate,
and avert my eyes from their rough exteriors.
> This, I believe, is a fundamental problem with
> HDLs that will not go away until something with
> the expressive power of CSP/occam surfaces in
> the HDL world.
... and some device vendors buy in.
> Of course, everyone who knows what they're doing
> has perfectly good ways to deal with this problem.
Yet everyone's code is uniquely difficult to read.
> It's not a show-stopper. But it presents a
> fundamental barrier to the development of
> hardware description beyond a crude block-level
> process-by-process approach.
As does the economy.
> Yours more in hope than in expectation,
Maybe things will line up better after
the next big bang.
-- Mike Treseler
Article: 137713"Muzaffer Kal": > An integer is a signed entity so if you're decrementing it, the first > time n-1 becomes less than zero is when n == 0. I think the idea was > that divider reg would get a decrement operator generator by carry > chain and then the final carry being set would indicate n-1 becoming > negative. It's a cute idea but synthesizer probably is not smart > enough to do operator sharing at the output of the decrementer and > instead builds a zero decoder at the output of the register. Ah, ok. Would this still apply if n was an array of signals? Gruss Jan BrunsArticle: 137714
On Jan 27, 9:50 pm, General Schvantzkoph <schvantzk...@yahoo.com>
wrote:
>
> > ----------------------------------------------------------------------
>
> > MAKE_DC_DC: process(clk)
>
> > variable toggle : std_logic := '0';
>
> > constant TICKS_CYC : integer := 32_000_000 / 128_000; constant
> > TICKS_HALF : integer := TICKS_CYC / 2;
>
> > variable divider : integer
> > range 0 to TICKS_HALF-1 := TICKS_HALF-1;
>
> > begin
> > if rising_edge(clk) then
> > DCLK <= toggle;
>
> > if ( (divider - 1) < 0 ) then
> > divider := (TICKS_HALF-1);
> > toggle := not toggle;
>
> > else
> > divider := divider - 1;
> > end if;
> > end if;
> > end process MAKE_DC_DC;
>
> > ----------------------------------------------------------------------
>
> I always add 1 bit to my counters and the use the MSB to do the reset,
> for example if I wanted to divide by 256 I'd do,
>
> reg [8:0] cntr;
>
> always@(posedge clk) begin
> if(sync_rst || cntr[8]) begin
> cntr <= 1;
> end
> else begin
> cntr <= cntr + 1;
> end
>
> This forces the synthesizer to use the sync set/reset inputs and the
> reset path will only have 1 LUT delay in it.
I tend to think in terms of hardware and once I know exactly what I
want from the hardware, I "describe" this in the HDL. In this case,
the carry out is not registered, so it can't really be described
inside the clocked process. I hedge with the word "really" because
this may be possible with the right coding style using variables. But
I prefer not to bother too much with "tricky" coding styles and to use
templates I have the most confidence in.
So I would code the counter logic as combinatorial logic and then
assign it to a register. Of course I can't say for sure this will
give you what you want, but I think it has a good chance.
constant TICKS_CYC : integer := 32_000_000 / 128_000;
constant TICKS_HALF : integer := TICKS_CYC / 2;
signal downcntr : integer
range -1 to TICKS_HALF-1 := TICKS_HALF-1;
signal divider... toggle... togglecntr...
MAKE_DC_DC: process(divider, toggle)
begin
if rising_edge(clk) then
DCLK <= toggle;
downcntr <= divider - 1;
if (downcntr < 0) then
divider := (TICKS_HALF-1);
togglecntr := not toggle;
else
divider := divider - 1;
end if;
end if;
end process MAKE_DC_DC;
MAKE_DC_DC: process(clk)
begin
if rising_edge(clk) then
divider := mod(downcntr, TICKS_HALF);
toggle := togglecntr;
end if;
end process MAKE_DC_DC;
If this form gives you the carry test that you are looking for, then
maybe you can combine the two processes into one and get the same
logic. The trick will be to use variable assignments to set the
variable and compared to -1 before the final assignment that is
latched into the register. I haven't tested any of this, so I may be
all washed up. I don't typically use variables.
I'm actually more interested in the fact that you consider
"spelunking" in the FPGA editor to be "fun"... ;^)
Rick
Article: 137715On Jan 28, 3:01=A0am, secure...@gmail.com wrote: > Hi Brian Drummond > > > It may be worth looking athttp://www.freepcb.com/ > > I tried this last year and it looked OK for a 676 pin 1mm BGA. > > (If you cross-check the Gerber output carefully!) I didn't get as far a= s > > finishing the board though. > > But with CS486, the pins are very close, 0.8 mm ... That doesn't really affect a choice of design software. 0.8 mm is actually fairly large in terms of the layout tools and PCB technology. It will be the via sizes and track widths that challenge the board makers (although there are plenty who can makes these boards). The PCB tools are selected more on ease of use and "special" features you may need. A 0.8 mm BGA does not require any "special" features from the software. Be sure to check with the chip maker for the details of the pads and included vias. They want your design to work and have lots of info on how to do that. RickArticle: 137716
On Jan 27, 9:08=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > On Jan 25, 10:34=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > > > Now when xilinx web is back online, well they do no have not a single > > reference design for the ethernet using SFP optical links > > all the demos are for the marvell SGMII phy only > > > i tried to change the TEMAC PHY form SGMII to 1000base-x but > > unfortunatly the system did not work after that. > > well all phy registers readback 0, so maybe there is some major > > problem with some clocking, and there are no other changes > > required, but i kinda can not belive that xilinx has not ever > > made a base1000-x based system for some of their board (ml405/ml505..) > > > Antti > > ok, i have a reference design, but our own SFP/ethernet design still > doesnt work after MPMC2-MPMC3 migration > > Antti it all works!! but we had to decrypt some more xilinx encrypted IP core sources and change low level settings of the MGT and hard TEMAC AnttiArticle: 137717
Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> writes: <snip> > (Historical note for old grumps like me: Thirty > years ago, occam and CSP had this sorted out, with > arbitrary sequential and parallel composition of > processes at all levels of the hierarchy. I bought a book on Transputers (Transputer system design or some such) in a 2nd hand bookshop on holiday a few years ago. It all seemed so sensible! Does that make me an old grump too I wonder? > But people who said "never liked threads" killed it dead. Ho hum :( > One day the wheel will turn, but not until the C programmer hegemony > is smashed.) > Is that more or less likely now that Mentor has bought the occam/CSP-derived Handel-C from Agility? http://eetimes.eu/uk/212902105 Will CatapultC gain some explicit parallelism? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 137718
secureasm@gmail.com wrote: > Hi Alex, > >> Even the best autorouters make ugly boards. > > It seems that all producers of software pcb, pointing to this > "Autoroute" are all lies ? > There are many PCB designers who believe autorouters are useless because they can make so much better boards with manual routing. I have no idea what the statistics are, but for my own use, I think autoroutering combined with a little manual routing is the only sane way to do a layout. Here's a few brief facts and opinions (they are "facts" if you agree with them, "opinions" if you do not...) Manual routing takes a *long* time, especially if you don't have much experience. Manual routing can be very tedious, especially with large numbers of nets, and if your design tools are not good enough. Manual routing gives you much better control over your tracks and where they run. Autorouting is *fast*. Manual routing can let you make more elegant routing. Autorouted boards often look more "mechanical". You need a *good* autorouter. Most of the complaints and myths about autorouting (such as claims that they need more layers) are based on older gridded autorouters. A poor quality autorouter is not much help to anyone. With autorouting, you can easily rip up the routes, shuffle around your components, and re-route. With manual routing, large changes to the board will lead to enormous duplication of effort. Even when autorouting, you normally want to do *some* manual routing. Things like switched mode supplies and fine analogue parts often benefit from manual routing. With autorouting, be very careful about power routing. It can be worth doing manually, or at least considering it in your autorouting setup. Autorouters may not support things like impedance control or differential pair routing, or these may be an expensive add-on. For more serious cards, you need to put a lot of effort into the autorouter setup, the passes it will run, etc. If the autorouter doesn't have a way to script such setup, get a better autorouter. If you are not an expert at manual routing, the autorouter will do a better job (shorter tracks, less vias, etc.) in many situations. A large card might take a month to manually route, but only a few days to do the critical manual routes and to get the autorouter setup working well. When version 2 of the card has significant changes, the manual re-routing takes a couple of weeks, and the re-autorouting takes a day. It all boils down to a balance between time and quality of the routing, and depends on the designer and the card in question.Article: 137719
secureasm@gmail.com wrote: > Hi Alex, > >> Even the best autorouters make ugly boards. > > It seems that all producers of software pcb, pointing to this > "Autoroute" are all lies ? They are not. Autorouters do automatic routing as advertised. The only problem is that the results can not be compared with manual routing. Maybe I just don't know how to use them right, but nobody I know uses autorouting for serious work. Sometimes you can let an autorouter do part of the job. -Alex.Article: 137720
"Martin Thompson" <martin.j.thompson@trw.com> wrote in message news:uocxrkagc.fsf@trw.com... > Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> writes: > > <snip> >> (Historical note for old grumps like me: Thirty >> years ago, occam and CSP had this sorted out, with >> arbitrary sequential and parallel composition of >> processes at all levels of the hierarchy. > > I bought a book on Transputers (Transputer system design or some such) > in a 2nd hand bookshop on holiday a few years ago. It all seemed so > sensible! Does that make me an old grump too I wonder? > >> But people who said "never liked threads" killed it dead. > > Ho hum :( > >> One day the wheel will turn, but not until the C programmer hegemony >> is smashed.) >> > > Is that more or less likely now that Mentor has bought the > occam/CSP-derived Handel-C from Agility? > > http://eetimes.eu/uk/212902105 It is less likely since Mentor is not the only company that is trying to crack the panacea of hardware design using a sequential language. Cadence recently announced their C to Silicon compiler and only a few days ago Synfora announced a 250% revenue growth. All I can say is *great*, I am a strong believer that this is the way forward. The human brain is not that well suited to think concurrently and hence engineers tend to write many more correct lines of code in a sequential language than in an HDL language. Unfortunately as far as I know all these tools still only work on datapath and sorting out the control part is a very difficult nut to crack. > > Will CatapultC gain some explicit parallelism? It is highly unlikely CatapultC will support Handel-C which is a good reason to a certain degree, the whole point of these tools is to tell you which resources can run in parallel rather than you telling the tool. Hans www.ht-lab.com > > Cheers, > Martin > > -- > martin.j.thompson@trw.com > TRW Conekt - Consultancy in Engineering, Knowledge and Technology > http://www.conekt.net/electronics.htmlArticle: 137721
On Wed, 28 Jan 2009 00:35:26 +0000, Brian Drummond wrote: >In one sense, signals are already very similar to occam's >channels, in that their events communicate synchronisation. For sure, but there's a big difference: signals are broadcast and non-negotiated. occam channels handshake (rendezvous) between a single source and a single sink. To do that in HDL requires at least two signals, one in each direction, with all the fuss and poor encapsulation that entails. SystemVerilog's interface construct might offer a way out, but [self publicity alert] as I'll discuss in a paper at DVCon next month, interfaces have many shortcomings that need sorting out before they are useful for reasonably high-level design. Of course, the Ada task entry rendezvous does all that occam channels do, and more; it's something I sorely miss in HDLs, especially when writing testbenches. > And that [HDL signals] works well in simulation. Yes, the discrete-event simulation model is powerful and highly appropriate for digital simulation at a fairly low level. No-one in their right mind would want to jettison that, with the enormous benefits it has brought to digital design. I'm just saying that we could move on a little further, but there doesn't seem to be any collective appetite for doing so. >The trouble of course is synthesis; almost all of that gets lost, >because those damn flip-flops only understand one clock; and Xilinx >STILL won't put Reed-Muller gates (choose another self-timed primitive >if you prefer) on their chips! (Achronix, anyone? Though it could take >synth tools a while to catch up...) Achronix looks really interesting, but note that they are currently marketing it as a way to get high performance ** while preserving a synchronous design style **. They appear to have found a way to get traditional synthesis tools to work with their technology, but unfortunately their dev kit is way too expensive for idle speculative experimentation so I know no more than what it says on their web site. Handshake Solutions offer a CSP-like language "Haste" that can be synthesised to asynchronous hardware (using Muller C-elements and various other tricks, I believe) but it seems far-fetched to imagine FPGAs being a viable target any time soon. >So we have to re-invent our composition mechanisms again in >excruciatingly low level detail. Yes. Don't hold your breath waiting for that to change :-( -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 137722
On Wed, 28 Jan 2009 11:29:23 -0000, "HT-Lab" wrote: >The human brain is not that >well suited to think concurrently I absolutely, fundamentally disagree. If you're stuck in a purely-sequential straitjacket, you are forced to jump through absurd hoops to express concurrent activity. What could be more natural than to say (or think) "Do XYZ; but while you're doing it, do as much of ABC as you can do without knowing the results of XYZ"? The widespread public distaste for concurrent descriptions simply reflects the fact that our tools for writing those descriptions are poorly matched to people's expectations. Above all else, what's needed is flexible composition of parallel and sequential descriptions, together with clear and intuitive ways to express synchronisation. CSP works for me, but not (it seems) for everyone. Typical real-time operating systems seem to me to make a truly lousy job of it, being designed for convenience of implementation rather than for expressive power. Just my $0.02. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 137723
>Even when autorouting, you normally want to do *some* manual routing. >Things like switched mode supplies and fine analogue parts often benefit >from manual routing. A lot of that sort of stuff "just works" with an autorouter if you have a decent placement. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 137724
On Jan 23, 11:24=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > it seems that first references to the upcoming Spartan family are in > the wild already > > http://www.linkedin.com/in/ericschristiansen > > I assume thespartan-6mentioned there is not a typo > (actually i am almost sure it isnt) > > Antti it seems that printed version of EE Times has already Virtex-6 Spartan-6 advertizments in it. can not verify as do not have yet a print copy the target url should be www.xilinx.com/6 so we should probably see there something pretty soon as Xilinx can not delay the RP announcement any more long when the print ads are alreayd running Antti
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