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
Kryten wrote:
> However many (most?) companies are in a mad rush to do things faster.
Documenting a design with text comments from the top down
and/or the bottom up, does not take any more total
time than any other method. You write them mainly
for yourself because design details are quickly forgotten.
> They don't see the point of slowing down code production for future benefit.
A good designer does not slow anything down.
> At one job, my predecessor was a fast coder, could re-write heaps overnight,
> but left the company with next to no documentation about how he meant his
> code to work. I spent heaps of time reverse engineering it, found lots of
> things to clean up, and some bits were just messy/confusing.
Non-trivial working code -- however ugly -- has value.
If you are modifying ugly working code,
don't edit it. Write a testbench for it.
Do the modifications as a wrapper module.
If the ugly code doesn't work, throw it away.
> The system had
> some kind of state machine I could not make elegant or modify without it
> falling over.
Make working code elegant is icing, not cake.
The top focus is to make the changes that the customer wants.
Make your own code elegant.
Focus on the needed changes first.
Recode the ugly module later if there is time,
but that is the final task, not the first.
> That job didn't last! Only my predecessor could understand it, which he did
> because his new job did not work out and he came back.
There is no need to understand the internal
details to write a testbench for a
working design module.
> One old cow-orker there had a closed mind: "Can't do it like that, there
> ain't time".
> Kept repeating statements like that so he didn't have to listen to heretical
> suggestions that things could be done better or differently.
If someone is not helping you,
don't waste a minute considering their opinions.
> If you are an employer, be aware of the consequences of letting coders skip
> documentation.
> They will have you by the snarglies when they ask for a pay rise and you
> dare not let them go.
> (hmm, that's not encouraging coders to document stuff is it?)
No it isn't.
A professional designer is self-motivated.
He documents as he goes because it is the
fastest way to get the job done.
-- Mike Treseler
Article: 85751"Mike Treseler" <mike_treseler@comcast.net> wrote in message news:mpWdneBHus7J2C3fRVn-iA@comcast.com... > Documenting a design with text comments from the top down > and/or the bottom up, does not take any more total > time than any other method. You write them mainly > for yourself because design details are quickly forgotten. Well, documentation is widely considered an unwelcome nuisance job to do, so rightly or wrongly it often gets left out. I agree that a modest yet useful mount of commenting takes little or no time. > A good designer does not slow anything down. Not everyone is a good designer. Demand outstrips supply. > Non-trivial working code -- however ugly -- has value. It wasn't working. > If you are modifying ugly working code, > don't edit it. Write a testbench for it. It was not in neat modular form that I could test individual modules. One early step was to section it into modules so I could know which ones were believed okay or not. > Do the modifications as a wrapper module. > If the ugly code doesn't work, throw it away. They would not let me. > Make working code elegant is icing, not cake. Agreed, but in this case it was impossible for me to see WTF was going on. Elegant I can read, inelegant I can read, but this was something else beyond that... > The top focus is to make the changes that the customer wants. > Make your own code elegant. > Focus on the needed changes first. > Recode the ugly module later if there is time, > but that is the final task, not the first. > >> That job didn't last! Only my predecessor could understand it, which he >> did because his new job did not work out and he came back. > > There is no need to understand the internal > details to write a testbench for a > working design module. Agreed. But this project didn't even have high-level specs to write a test for. It was a real-time control system so it was not practical for me to write a testbench to simulate loads of asynchronous events going on (joystick, emergency stop, limit switches, unplugged peripherals, etc). > If someone is not helping you, > don't waste a minute considering their opinions. Alas, their opinions dictate their actions which hindered progress and quality. > A professional designer is self-motivated. > He documents as he goes because it is the > fastest way to get the job done. I document/comment all my code to make my own life easier (like in a years time when I get asked to mod something) and as a side effect it would help those who inherit my code. Some more gifted coding virtuosos can carry it all in their head. Great for them, but makes life a bugger for mere demi-geeks like me.Article: 85752
You have to insert your own registers to make the pipeline a desired latency. You can then let the tool move the logic across those boundaries. How would you specify to the tool what you want pipelined, what you don't, and what the expected final latency in clocks is? You insert registers in the paths you want piped. The tool I use to insert registers: vi. "Davy" <zhushenli@gmail.com> wrote in message news:1118807485.054216.114960@g14g2000cwa.googlegroups.com... > Hi, > > Yes I know re-timing, it just push pull the register(rely on the > original netlist), but not insert register. > > Is there any tool to insert registers? > > Thanks! > DavyArticle: 85753
Seen on the Xilinx web site: "Attend a FREE Low Cost Seminar near you" It's actually free, not low cost. LeonArticle: 85754
"Leon" <leon_heller@hotmail.com> schrieb im Newsbeitrag news:1118850931.400133.325930@g49g2000cwa.googlegroups.com... > Seen on the Xilinx web site: > > "Attend a FREE Low Cost Seminar near you" > > It's actually free, not low cost. > > Leon > its probably free seminar about low cost FPGA's ? Lattice has similar seminars, they dont even mention other products then the low cost (EC/XP), Lattice did draw some marketing charts where the % of low cost FPGA s was grawing much faster than other areas. so everybody is pushing... AnttiArticle: 85755
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:jphsa1doui4mdv1dhnk389ar9dqa8smov2@4ax.com... > On Mon, 13 Jun 2005 09:29:26 -0700, "Symon" <symon_brewer@hotmail.com> > wrote: > > > >Single ended? > >Cheers, Syms. > > > > Yup. > Wow, I'm impressed! Single ended clock signal I guess, not random data? Cheers, Syms.Article: 85756
On Wed, 15 Jun 2005 09:49:36 -0700, "Symon" <symon_brewer@hotmail.com> wrote: >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >news:jphsa1doui4mdv1dhnk389ar9dqa8smov2@4ax.com... >> On Mon, 13 Jun 2005 09:29:26 -0700, "Symon" <symon_brewer@hotmail.com> >> wrote: >> > >> >Single ended? >> >Cheers, Syms. >> > >> >> Yup. >> >Wow, I'm impressed! Single ended clock signal I guess, not random data? >Cheers, Syms. > Here's one of our gadgets, built for the NIF laser... http://www.highlandtechnology.com/DSS/V880DS.html All the fast stuff is EclipsLite logic, pecl mode, and most of it is single-ended except for a major clock which is a diff microstrip. If you want low jitter, you have to know The Secret. JohnArticle: 85757
On Wed, 15 Jun 2005 15:37:13 GMT, "Kryten" <kryten_droid_obfusticator@ntlworld.com> wrote: > >"Mike Treseler" <mike_treseler@comcast.net> wrote in message >news:mpWdneBHus7J2C3fRVn-iA@comcast.com... > >> Documenting a design with text comments from the top down >> and/or the bottom up, does not take any more total >> time than any other method. You write them mainly >> for yourself because design details are quickly forgotten. > >Well, documentation is widely considered an unwelcome nuisance job to do, so >rightly or wrongly it often gets left out. > >I agree that a modest yet useful mount of commenting takes little or no >time. > > It takes less than no time. The act of commenting cuts debug time more than the time it takes to type the comments, becauses it forces the coder to think about what he's doing. Extreme Programming has similar dynamics: *two* programmers working on a single piece of code are more efficient than one! JohnArticle: 85758
you also have the init_signal_spy() command in modelsim that you have to add to your testbench ... "CODE_IS_BAD" <Puneetsingh81@gmail.com> wrote in message news:1118730828.471845.41380@g47g2000cwa.googlegroups.com... > Hi all, > I am using ModelSim PE 6.0d. I have done functional simulation for > my design (i could view all internal signals there) and that works > fine. When i run Post P&R simulation i get some misfunctionality. To > correct the same i need to view internal signals in the post P&R > simulation. But the same does not come if we check the signals listed > under UUT. > > I know this has been posted some time back also but i could not > understand correctly. If somebody knows the correct procedure then > please help. Thanx in advance. >Article: 85759
"Patrick" <patrick.melet@dmradiocom.fr> schrieb im Newsbeitrag news:54b3002.0506150202.5ba5002c@posting.google.com... > Sometimes, one of the three cards don't program them. > This is the MAX chip which program the FPGA through the Flash Memory. > This chip is connected to the 3.3V > > We notice that when the +3.3V is OK, the +1.5V is not really arrive to > 1.5V, and so I think that the MAX begin the programmation when the Vcc > core is not OK and that fail the programming sequence ? You found the problem. Its power sequencing. Use a voltage monitor to release a reset for the MAX after ALL voltages are stable. Regards FalkArticle: 85760
"Mike Treseler" <mike_treseler@comcast.net> schrieb im Newsbeitrag news:mpWdneBHus7J2C3fRVn-iA@comcast.com... > A professional designer is self-motivated. > He documents as he goes because it is the > fastest way to get the job done. Very good statement! 100 ACK! Regards FalkArticle: 85761
"Kryten" <kryten_droid_obfusticator@ntlworld.com> schrieb im Newsbeitrag news:JWXre.25126$iy2.8723@newsfe1-gui.ntli.net... > > Do the modifications as a wrapper module. > > If the ugly code doesn't work, throw it away. > > They would not let me. What you describe is one of the worst task for an engineer. Fix things that almost work (so thinks your boss, just some small fixes and all is going well). And the ***** that messed it all up is gone. I had this situation more than once, but luckyly the design wasnt too big and they let me throw away the code and rewrite it form the very beginning. But still, a dangerous situation. You end up as the scapegoat. Regards FalkArticle: 85762
> > As someone who is still working with Spartan II, I was amused to see that > > my mothers new television has a Spartan 3 inside ... > > Strange that - you'd have thought if you're making TV's you'd plan to sell > enough to pay for an ASIC Actually these TVs are generally based on atleast one ASIC (a video decoder and scaler), and an FPGA. The FPGA generally has some simple glue logic, sitting between the ASIC and the LCD panel. LCD panels from different manufacturers, many of which are available in mechanically compatible form factors, often have different electrical and timing characteristics. With the LCD panel the single largest cost item in a TV, leaving the glue logic programmable allows the manufacturers to treat the panel as a commodity item. I would not expect this FPGA "socket" to go away any time soon. Regards, Erik. --- Erik Widding President Birger Engineering, Inc. (mail) 100 Boylston St #1070; Boston, MA 02116 (voice) 617.695.9233 x207 (fax) 617.695.9234 (web) http://www.birger.comArticle: 85763
Ben Jones (ben.jones@xilinx.com) wrote: : > Yes I know re-timing, it just push pull the register(rely on the : > original netlist), but not insert register. : > Is there any tool to insert registers? : Well, inserting registers changes your design in a fundamental way. : Most circuits I can think of would just stop working if you added : registers to them at random. Only you, the designer, know exactly : how much pipelining it is legal to apply to a given part of your : circuit. So I don't believe such a tool exists - certainly not in the : general case. This is very true, but there's no reason a designer couldn't specify a bunch of signals (e.g. the data signal from a combinatorial multiply and associated control signals) and some tool would add aribtrary (to a user specified limit) stages of pipelining to all signals to meet timing, with logic/register shuffling. This would only work the control and data flows can be aribtrarily pipelined, but many ops can be described this way/ A half way house to acheive this is to use current register shuffling on the data signals and experimentally add registers to reach timing, and then pipline associated control signals. If done using a VHDL generate tc. it's a two second text editor job to do the later. If someone writes the tools then the whole operation could be scripted, with the logic to be messed and associated signals isolated in a soure file. All in all construtive use of a text editor on the source is much less hastle :-) --- cdsArticle: 85764
Evening... Seen in u-boot source code that before returning from an interrupt the return address is adjusted by "-4"... And interestingly this needs to be done although the NIOS2 datasheets says that the address of the next instruction is saved... thanx in advance rickArticle: 85765
Hi Jeremy, > Gary Pace wrote: >> Strange that - you'd have thought if you're making TV's you'd plan to >> sell enough to pay for an ASIC > > Could be a time-to-market thing :) Sell lots, then go to asic later. You're absolutely right. TV makers make a new TV asic every, let's say, three years, in order to minimize NRE cost. New features are being implemented in FPGA _and_ incorporated in the next-generation ASIC. After three years, you'll have an FPGA-less TV, with one _with_ FPGA (with new features) coming out the year after, etc etc. Also, I've written LCD driver code for [TV maker] so that they could be flexible with panel timing and signalling, thereby freeing them from panel maker lock-in, and start designing for panels whose specs weren't quite finished yet. Best regards, BenArticle: 85766
"himassk" <himassk@gmail.com> wrote in message news:1118828822.149261.240320@g14g2000cwa.googlegroups.com... > > Hi, > Can any body help me by giving website address or info > about VHDL synthesis coding techniques. > > Thank u. > > Hima. > http://www.fpga-site.com/tutorials.htmlArticle: 85767
Has anyone had any experience directly implementing BUFGMUX components in a Spartan-3 device. I know this sounds like a very simple task but I can't seem to get this thing to route. I am simply attempting to select between 2 separate clock signals and route them to a DCM to be deskewed prior to use throughout the device. The part is a Spartan-3 XC3S400-fg456c -4. The 2 clock signals are on the same side of the die and connected to GCLK-5&7 pins respectively. When I run this through Synplify Pro v8.1 and then through ISE7.1.2 I get a warning stating that the output pin of the BUFGMUX is not connected to a external net, and the tool adds the net / pad for me. Then when it moves on to build the DCM it fails do to the fact that the clkin pin of the DCM has multiple drivers the BUFGMUX and the pad that the tool added.Article: 85768
Thanx ppl. Can I do something like we do with any spartan device, I mean without using anything(Processor,IPs,Buses), can I map my application on Virtex2Pro? Thanx Regards spsArticle: 85769
I found out what the issue was: libPortability.dll is located in the directory %XILINX%\bin\nt. However, when you install ISE 7.1i, it sets the path to %XILINX%. For EDK to work properly, the path should be %XILINX%\bin\nt instead. Thus, the bug is that EDK should make sure that the path is %XILINX%\bin\nt, not %XILINX%. Note that ISE will work with either path configuration because Windows shortcuts (like clicking on the Project Nav icon) uses the absolute path, so ISE searches for its DLL in the path in which it resides. I noticed that the only time that xps.exe ran was when I called it from C:\Xilinx\bin\nt (from the DOS command prompt, cmd). This observation clued me in that there were some path issues. Fix: Make sure PATH variable has %XILINX%\bin\nt in it.Article: 85770
Does anyone know if there is a specific problem leading to long lead times for the Spartan3. Someone from one of the major distribitors said there was. Also, Xilinx no longer sells the Spartan3 on the website, whereas they used to do so. An answer would be appreciated as I want to use this part and already have it designed in.Article: 85771
Hi Steve, To clarify it for me, what is the likely lead times AFTER August for the lower density Spartan3's, eg., xc3s200? Thanks, A long time Xilinx customerArticle: 85772
Ray Andraka wrote:
> Time has come for a computer upgrade (I'm currently using a dual
> Athlon 1.8GHz with 4GB memory and 15000RPM scsi raid array running
> Win2K, matrox dual head video with a pair of 19" monitors), but I
> haven't kept up at all with the computer market. I'm wondering what
> people are using these days for high end designs (for simulation and
> PAR especially). I'd like something that doesn't sound like a vacuum
> cleaner and heat the room like a space heater this time around too,
> perhaps I need to consider liquid cooling? ANy comments would be
> appreciated. Yes, I admit I am being lazy.
>
Thanks all who replied. You've given me lots to chew on.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 85773I thing Steve Knapp (Applications Manager for Spartan FPGAs) posted it quite succinctly: Steve Knapp posted: Xilinx is transitioning the lower-density Spartan-3 FPGAs (XC3S50 through XC3S1500) from the 200 mm wafer production line to the 300 mm line. The larger density Spartan-3 FPGAs (XC3S2000 through XC3S5000) are already built exclusively on the 300 mm line. Xilinx has a policy where we notify customers 90 days in advance of such a change and we cannot ship product from the new fab unless you specifically order us to. This gives customers 90 days to evaluate the new material to see if it affects their production systems. The details are in the following change notice. http://www.xilinx.com/bvdocs/n otifications/xcn05009.pdf Starting 1-AUG-2005, all orders will be shipped from the 300 mm line. Until then, all production orders for lower-density Spartan-3 FPGAs are still shipped from the 200 mm line. As a consequence, lead times are artificially increasing during the transition. There are plenty of 300 mm devices in stock. However, due to our notification policy, we can't ship you one of the 300 mm devices unless you specifically ask. You can dramatically improve delivery by appending the part number with the four-number code "0974". For example, "XC3S200-4PQ208C" would become "XC3S200-4PQ208C0974". End of quote. I aplogize for the inconvenience and the apparent bureaucratic fumble, but this is the best you can do. We have plenty of parts. The problem is getting them into your hands. Peter Alfke, Xilinx ApplicationsArticle: 85774
On 15 Jun 2005 17:23:06 -0700, Peter Alfke wrote: > I thing Steve Knapp (Applications Manager for Spartan FPGAs) posted it > quite succinctly: > > Steve Knapp posted: > Xilinx is transitioning the lower-density Spartan-3 FPGAs (XC3S50 > through > XC3S1500) from the 200 mm wafer production line to the 300 mm line. > The > larger density Spartan-3 FPGAs (XC3S2000 through XC3S5000) are already > built > exclusively on the 300 mm line. Xilinx has a policy where we notify > customers 90 days in advance of such a change and we cannot ship > product > from the new fab unless you specifically order us to. This gives > customers > 90 days to evaluate the new material to see if it affects their > production > systems. The details are in the following change notice. > http://www.xilinx.com/bvdocs/n otifications/xcn05009.pdf > > Starting 1-AUG-2005, all orders will be shipped from the 300 mm line. > Until > then, all production orders for lower-density Spartan-3 FPGAs are still > > shipped from the 200 mm line. As a consequence, lead times are > artificially > increasing during the transition. There are plenty of 300 mm devices > in > stock. However, due to our notification policy, we can't ship you one > of > the 300 mm devices unless you specifically ask. You can dramatically > improve delivery by appending the part number with the four-number code > > "0974". For example, "XC3S200-4PQ208C" would become > "XC3S200-4PQ208C0974". > End of quote. > > I aplogize for the inconvenience and the apparent bureaucratic fumble, > but this is the best you can do. We have plenty of parts. The problem > is getting them into your hands. > Peter Alfke, Xilinx Applications Is this from UMC or Toshiba? Or Both? Will the current specifications be maintained? Or is there a new specification to deal with the change in process/FAB?
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