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
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:3FAB4DAA.28A58C19@yahoo.com... > Austin Lesea wrote: > > > > John, > > > > Nope. 1st law says that energy is conserved. Can not lose it. > > > > Austin > > > > John Smith wrote: > > > > > > Aggghhhh.... I'm gonna be on 2ndlaw.com, and its sister, I may be a while... > > > > > > Thanks for the answers guys. 'Lost' energy (non-recoverable energy) is my > > > summary. Correct? > > > > > > Thanks again > > > JS > > John, > > Don't let this confuse you. In reality "lost" energy is still energy. > But it is lost in the sense that you can't do anything useful with it. > It becomes spread out evenly as heat otherwise known as "disorder". > Only "orderly" forms of energy can be used. > > Heat is only useful (orderly) if there is more of it here than there, > then you can get some useful work from it by tapping it as it flows from > here to there. But then both here and there are at the same temperature > and you can do no more work with that energy. In that sense, it is > "lost". > > -- > > 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 I did get the drift of it, hopefully the previous poster hadn't had his morning coffee yet. Thanks JSArticle: 62776
In comp.arch.fpga rickman <spamgoeshere4@yahoo.com> wrote: : Don't let this confuse you. In reality "lost" energy is still energy. : But it is lost in the sense that you can't do anything useful with it. : It becomes spread out evenly as heat otherwise known as "disorder". : Only "orderly" forms of energy can be used. Energy: Total Exergy: Usable part of total energy Anergy: Unusable part of total energy : Heat is only useful (orderly) if there is more of it here than there, : then you can get some useful work from it by tapping it as it flows from : here to there. But then both here and there are at the same temperature : and you can do no more work with that energy. In that sense, it is : "lost". Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 62777
Hi John, The new instruction in MicroBlaze for handling these locallinks are simple but there is no HW scheduler in MicroBlaze. I have done processor before with complete Ada RTOS in HW but it would be an overkill in a FPGA: The Locallinks for MicroBlaze is 32-bit wide so they are not serial. They can handle a new word every clock cycle. <rand mode on> MicroBlaze has 8 new instructions for handling the Locallinks (or I call them FSL) FSL = Fast Simplex Links The are mainly two instruction with each four options. The instruction for reading from a FSL is called GET GET rD, FSL #n This will get a word from the FSL number #n and move the data into register rD The instruction for writing a value to a FSL is PUT rA, FSL #n This will move the value in register rA to FSL #n Each FSL has a FIFO which will control if there is available data on the FSL or if the FSL is full. If you try to do a GET when the FSL is empty, MicroBlaze will stall until the data is there and if you try to do a PUT on a FSL which is full, MicroBlaze will stall until space is available on the FSL. So the normal GET and PUT is blocking which is great when you communicate with HW since there is no "read status bits, mask status bits, branch back if not ready" loop which will reduce any kind of bandwidth with HW. HW tends to be much faster than SW so in general the blocking instruction will never block. One option on the instruction is to have a nonblocking version of GET and PUT which are called nGET and nPUT. These will try to perform the instruction and the carry bit will be set if they were successful and it will be cleared if they failed. This will make it possible to try communication on the FSL. The FSL also have a extra bit which is done for sending more than 32-bit data, you can consider this as a tag information. We call it "control". Normal PUT will set this signal to '0' but the cPUT will set it to '1'. The Control signal is stored as the data in the FIFO so the FIFO's are really 33 bit. This extra bit permits more synchronization and control/data flow betwene to FSL units. The normal usage of FSL is to analyze your c-code and find a function where the MicroBlaze spends most of the cycles. Moce this function in the HW (there are getting moreand more C-to-HW tools). Create a wrapper in C with the same function name as the HW function. This wrapper will just take all the parameter and PUT them onto a FSL and then it's do a GET. You could also connect up a massive array of MicroBlaze over FSL ala transputer but I think that the usage of the FPGA logic as SW accelarators will be a more popular way since FPGA logic can be many magnitudes faster than any processor and with the ease of interconnect as the FSL provides it will be the most used case. <rant mode off> Göran john jakson wrote: >Goran Bilski <goran@xilinx.com> wrote in message news:<bocq73$bgh1@cliff.xsj.xilinx.com>... > > >>Hi, >> >>I have been following this thread with great interest. >> >>If you need a processor with links to/from the processor register file >>then MicroBlaze could be the answer. >> >>MicroBlaze has 18 direct links (in the current version, the ISA allows >>up to 2048) and 8 new instructions for sending >>or receiving data to/from the register file. >> >>The connection is called LocalLink (or FSL) and has this features >>- Unshared non-arbitrated communication >>- Control and Data support >>- Uni-directional point-to-point >>- FIFO based >>- 600 MHz standalone operation >> >> >> >- > >Hi Goran > >What I am really after is a speedy Transputer, better still many of >them distributed inside & across FPGAs. Not the original with funny >8bit opcodes (partly my fault) but a modern design that is RISC & >targeted to FPGA using MicroBlaze as a HW/performance reference. I >would budget for about 2x the cost before thinking of FPU, still >pretty cheap. > >The important part is the ISA supports process communication >transparently with scheduler in HW. The physical links internal or >external is only a part of it. Since many cpus now have these links, >and serial speeds can be far in excess of cycle speed, thats nice, but >no use if the programmer has to program them themselves. With an >improved event wheel scheduler in HW too, HW simulation becomes >possible for HW that might be "hard" or "soft", but then HW in FPGAs >are not strictly "hardware" either (see old thread). So if HW & SW can >be somewhat interchanged, it becomes easier to migrate large C seq >problems gradually into C-Occam par/seq then into more HDL par all >from inside one (maybe ugly)language. It would be even nicer to start >over with a new leaner language that can cover HDL & SW but its more >practical to fuse together the languages people actually use. > >Who is the potential customer for this, any SW-HW person interested in >speeding up SW like the original poster or any embedded engineer that >wants to customize cpu with own HW addons using Occam style channels >to link them. I could go on, but much work to do. > > >John > >johnjaksonATusaDOTcom > >Article: 62778
> Now my question is: Is the ASIC speed result reliable? If it's from DC, then no. Since we didn't > do P&R( we don't have tools and experiences ), I really doubt the > timing report may be over optimistically estimated and not reliable. I > was told something about "wire load model" and ours is automatically > selected by the compiler. Knock off 20%, as you're likely to have a more realistic figure. If you're working at .13, you probably want to be using physical synthesis rather than synthesis based on wire load models. JonArticle: 62779
"Andras Tantos" <andras_tantos@tantos.yahoo.com> wrote in message news:<3fa942a5@news.microsoft.com>... > > I will write a open source arm vhdl model from > > this month on. I hope to have it ready in > > approximately 2 months using LeonSoc as a framework > > and implementing a arm1 integerunit. Anyone that wants > > to participate is wellcome. > > Konrad Eisele > > Many tried, all got kicked in the back by ARM. If you can create something > useful, get ready for a contact from one of their lawyers, I wrote my own clone earlier this year (just haven't got around to releasing it yet). I spent quite a bit of time studying the patent issues, and believe that you should be able to implement the basic V4 instruction set (This doens't include Thumb). The only real hurdle is then likey to be patent 5,386,563 which deals with the exception processing mechanism. However, I believe this patent to be invalid, as there is a significant amount of prior art (Search for "ARM's dubious patents" in comp.arch). Cheers, JonBArticle: 62780
antti@case2000.com (Antti Lukats) wrote in message news:<80a3aea5.0311060129.38e3476a@posting.google.com>... > "Andras Tantos" <andras_tantos@tantos.yahoo.com> wrote in message news:<3fa942a5@news.microsoft.com>... > > > I will write a open source arm vhdl model from > > > this month on. I hope to have it ready in > > > approximately 2 months using LeonSoc as a framework > > > and implementing a arm1 integerunit. Anyone that wants > > > to participate is wellcome. > > > Konrad Eisele > > > > Many tried, all got kicked in the back by ARM. If you can create something > > useful, get ready for a contact from one of their lawyers, > > > > Andras Tantos > > why write it from scratch? the nnARM source codes can be found with google > with no problems. the synthesis result is unfortunatly quite big fits > barely into XC2S600E > > would be nice to have smaller core though ;) > > antti > PS the ARMlayers tried to take nnARM off from public internet, but its > still downloadable, so the layers are not doing very good job. I'm not sure if it has been worked on since the last time I saw it, but I don't believe the nnARM could really be used as is. Didn't it just come with a behavioural memory interface? I also seem to remember the pipeline being pretty shallow, meaning it isn't exactly going to go very fast. Cheers, JonArticle: 62781
> > > > I will write a open source arm vhdl model from > > > > this month on. I hope to have it ready in > > > > approximately 2 months using LeonSoc as a framework > > > > and implementing a arm1 integerunit. Anyone that wants > > > > to participate is wellcome. > > > > Konrad Eisele > > > > > > Many tried, all got kicked in the back by ARM. If you can create something > > > useful, get ready for a contact from one of their lawyers, > > > > > > Andras Tantos > > > > why write it from scratch? the nnARM source codes can be found with google > > with no problems. the synthesis result is unfortunatly quite big fits > > barely into XC2S600E > > > > would be nice to have smaller core though ;) > > > > antti > > PS the ARMlayers tried to take nnARM off from public internet, but its > > still downloadable, so the layers are not doing very good job. > > Doesn't really matter, good enough in this case, lets any potential > commercial user get the message loud & clear. If its a 600 target, > thats one very expensive Arm compared to real thing. For an opensource > cpu to be useable, it must be competitive in size, speed, power with > commercial cpus. And if you want to be better than the competition, don't base your design on ARM. It has (IMHO) a huge flaw in the architecture (shifting), that means if you want decent performance, you end up having to add tons of extra logic. JonArticle: 62782
Hi I am designing a board using spartan3 1.5million device. I got few questions 1. I am planning to configure the device using a host DSP. The interface is 3.3 V and slave serial mode. I am connecting a series resistor between the DSP dicrete & PROGB of FPGA to make it tolerant and so for CCLK and DIN. I am pulling DONE INIT to 3.3 V for the same reason. Am I correct i this? 2. Please suggest suitable decoupling for the power supply. Rgd AnjanArticle: 62783
Hi Chuck
Many thanks for your input on my question.
I have used your code and it leaves me with just one problem in my
simulator that you may be able to advise me on.
It is a warning that Net "/clear" does not set/reset
"/".../Store_trigger_Acquisition_Count_reg<0>
all other bits for Store_trigger_Acquisition_Count get the same
warning.
The result is that the synthesis tool warns that no global set/reset
(GSR) net could be used in the design as there is not a unique net
that sets or resets all the sequential cells.
I have modified your code to include the use of the clear signal to
set Store_Trigger_Acquisition_Count
to 0. This has had no effect.
Any suggestions?
always @ (ACB_Decade_Count_Enable or OUT_Acquisition_Count or clear)
if(clear)
Store_Trigger_Acquisition_Count <= 14'b0;
else
begin
if(ACB_Decade_Count_Enable) // event happened input is high.
Store_Trigger_Acquisition_Count <= OUT_Acquisition_Count;
end
always @ (posedge clear or posedge ACB_Read_Trigger_Address_Clk )
begin
if(clear)
out_count <= 4'b1110;
else
out_count <= out_count - 1;
end
Many thanks for your input.
Denis
"Chuck Levin" <clevin1234@comcast.net> wrote in message news:<u-udnRdzu_xrzDeiRVn-ug@comcast.com>...
> The problem is that you have assigned signal Store_Trigger_Acquisition_Count
> in two processes.
> One possible solution is the following ;
>
> always @ (ACB_Decade_Count_Enable or OUT_Acquisition_Count)
> begin
> if(ACB_Decade_Count_Enable) // event happened input is high.
> Store_Trigger_Acquisition_Count <= OUT_Acquisition_Count;
> end
>
> always @ (posedge clear or posedge ACB_Read_Trigger_Address_Clk )
> begin
> if(clear)
> out_count <= 4'b1110;
> else
> out_count <= out_count - 1;
> end
>
> assign ACB_Trigger_Address_Output =
> Store_Trigger_Acquisition_Count[out_count];
>
>
> This solution creates a latch for Store_Trigger_Acquisition_Count and then
> uses an internal down counter to mux the Output under control of the clock.
>
>
> "Denis Gleeson" <dgleeson-2@utvinternet.com> wrote in message
> news:184c35f9.0311060253.19553d1f@posting.google.com...
> > Hello all
> >
> > I am trying to implement the following logic in a xilinx XCS05xl
> > FPGA.
> >
> > I have a 15 bit binary counter. I need to store its count value
> > on the occurrence of an event. Some time later I need to shift the stored
> > counter value out of the FPGA in a serial fashion under the control
> > of a clock.
> >
> > What I currently have is:
> > -----------------------------------------------------------------------
> > input clear;
> > reg clear;
> >
> > input ACB_Decade_Count_Enable;
> >
> > input ACB_Read_Trigger_Address_Clk;
> >
> > output ACB_Trigger_Address_Output;
> > reg ACB_Trigger_Address_Output;
> >
> > reg [14:0] Store_Trigger_Acquisition_Count; // Storage for counter count.
> >
> >
> > // Store the count value when ACB_Decade_Count_Enable is high.
> > always @ (ACB_Decade_Count_Enable)
> > begin
> > if(ACB_Decade_Count_Enable) // event happened input is high.
> > Store_Trigger_Acquisition_Count <= OUT_Acquisition_Count;
> > end
> >
> > // Now shift out the stored count serially.
> > always @ (posedge clear or posedge ACB_Read_Trigger_Address_Clk)
> > begin
> > if(clear)
> > begin
> > ACB_Trigger_Address_Output <=0;
> > end
> > else
> > begin
> > ACB_Trigger_Address_Output <=Store_Trigger_Acquisition_Count[14];
> > Store_Trigger_Acquisition_Count <= Store_Trigger_Acquisition_Count << 1;
> > end
> > end
> >
> > -----------------------------------------------------------------------
> >
> > With this code my synthesis step gives the following errors.
> >
> > Warning - Latch inferred in design "My block" read with
> > 'hdlin_check_no_latch'(HDL - 307)
> >
> > Error - The net /../my block/Store_Trigger_Acquisition_Count<13> has
> more
> > than one driver(FPGA-CHECK-5)
> >
> > The last error is repeated for all bits in
> Store_Trigger_Acquisition_Count.
> >
> >
> > The logic above seems correct in my head but Im not an FPGA expert.
> > Obviously I need a different implementation. Any suggestions.
> >
> >
> > Many thanks for all suggestions in advance.
> >
> > Denis
Article: 62784Hello, In a current FPGA-based design, I have a sub-block whose synchronous outputs drive some logic such as counters & flip-flops(external to the sub-block but internal to the FPGA). The current design has the sub-block synchronously enabled when it needs to be used and synchronously disabled when it does not need to be used. When the block is de-selected (going from enabled to disabled), I would like the sub-block's flip-flops to be reset, so the next time the block is enabled, the outputs are in a known state. My question: Is it safe to use a synchronous reset signal which is high for one system clock cycle to drive the async reset on the flip-flops of my sub-block? Note: The sub-block flip-flops are synchronously disabled before being reset by the synchronous reset signal, so I am not creating a setup/hold time problem with the sub-block FFs. My real concern is about violating the setup & hold time on the flip-flops the sub-block drives. My thinking is that even though the reset signal is synchronous, the sync. reset signal will probably not be distributed via a low-skew line (aka global signal) and I could potentially have a far sub-block flip-flop not reset by the time the clock comes around, and thus I clober a flip-flop which is driven by a s-b FF. If driving the async. reset on the FFs is a bad idea, my other approach was to take each DFF of the sub-block and update it to include a 2-input AND gate on the input. One input to the AND2 gets the original D-input signal while the second input gets a NOTed SCLR(active high), so I create a synchronous clearable DFF. I would appreciate comments, suggestions, etc. JayArticle: 62785
john jakson wrote: > What I am really after is a speedy Transputer, better still many of > them distributed inside & across FPGAs. Not the original with funny > 8bit opcodes (partly my fault) but a modern design that is RISC & > targeted to FPGA using MicroBlaze as a HW/performance reference. I > would budget for about 2x the cost before thinking of FPU, still > pretty cheap. Hi John, do you know about this nice stuff developed by Cradle (http://www.cradle.com) ? They have developed something like an FPGA. But the PFUs do not consist of generic logic blocks but small processors. That's perhaps something you would like :-) Regards, MarioArticle: 62786
On Thu, 06 Nov 2003 07:50:23 -0800, Austin Lesea <Austin.Lesea@xilinx.com> wrote: >Morten, > >With the FROM:TO constraints I have always found them applying to things that >I did not want them to. To really get the constraint "correct" (so that it >didn't want to apply it to something else), I had to use FROM:THROUGH:TO >(specify the path in question). > >After mucking about with this for a long time, and failing to get a >reasonable result, I just pulled the constraints, and used the period >constraint all alone. The multicycle through paths now did not meet timing >(failed), but at least I could go and manually check each one, and "sign off" >that these paths were OK none the less. Have you filed a case with the hotline? >The area was also massively affected by the FROM:THOUGH:TO constraints, with >very poor timing results (worse than the period constraint alone) resulting >on the paths that I really cared about and larger area..... Probably should file a case on this too. >I suppose that if I had a single clock things would have worked better, but >with multiple clock domains, resynchonization circuits, and the rest of the >stuff, the FROM:TO constraints just seemed to be causing me nothing but >headaches. Maybe file a case on this? >(as the synthesizer just seemed to want to apply relaxed >constraints to too many paths). ok, I'll shut up now. >Austin PhilipArticle: 62787
johnjakson@yahoo.com (john jakson) wrote in message news:<adb3971c.0311061709.5ca8cff7@posting.google.com>... > antti@case2000.com (Antti Lukats) wrote in message news:<80a3aea5.0311060129.38e3476a@posting.google.com>... > > "Andras Tantos" <andras_tantos@tantos.yahoo.com> wrote in message news:<3fa942a5@news.microsoft.com>... > > > > I will write a open source arm vhdl model from > > > > this month on. I hope to have it ready in > > > > approximately 2 months using LeonSoc as a framework > > > > and implementing a arm1 integerunit. Anyone that wants > > > > to participate is wellcome. > > > > Konrad Eisele > > > > > > Many tried, all got kicked in the back by ARM. If you can create something > > > useful, get ready for a contact from one of their lawyers, > > > > > > Andras Tantos > > > > why write it from scratch? the nnARM source codes can be found with google > > with no problems. the synthesis result is unfortunatly quite big fits > > barely into XC2S600E > > > > would be nice to have smaller core though ;) > > > > antti > > PS the ARMlayers tried to take nnARM off from public internet, but its > > still downloadable, so the layers are not doing very good job. > > Doesn't really matter, good enough in this case, lets any potential > commercial user get the message loud & clear. If its a 600 target, > thats one very expensive Arm compared to real thing. For an opensource > cpu to be useable, it must be competitive in size, speed, power with > commercial cpus. > > johnjaksonATusaDOTcom Does anyone know when the arm license is going to expire?Article: 62788
I wrote:
>
> Possibly Helpful Answer Records:
>
oops, I left off one with a good description of manual IOB timing
calculations required to correct reported DDR setup times:
18079 The input setup/hold requirement reported by TRCE seems
excessive for my design; is the value correct?
Brian
Article: 62789Phil Hays <SpamPostmaster@attbi.com> wrote in message news:3FAA5342.B1F91A03@attbi.com... > The current law makes salaried people not get paid overtime. If you don't think > that is fair, you need to convince voters to elect people that will change the > laws. Surely all the law says is that if you sign a contract of employment which say you don't get paid overtime, then you can't expect to get paid for overtime? It's up to you whether you sign in the first place. ? NialArticle: 62790
rickman wrote: ... > Don't let this confuse you. In reality "lost" energy is still energy. > But it is lost in the sense that you can't do anything useful with it. > It becomes spread out evenly as heat otherwise known as "disorder". > Only "orderly" forms of energy can be used. > > Heat is only useful (orderly) if there is more of it here than there, > then you can get some useful work from it by tapping it as it flows from > here to there. But then both here and there are at the same temperature > and you can do no more work with that energy. In that sense, it is > "lost". Nicely put. A corollary is that when everything is at the same temperature, nothing can be seen. Some electric ovens have a covered eye hole so that one can see what's happening by swinging aside the flap and peering in. There is often enough glow from the hot walls to show the work. The work disappears at equilibrium, when it reaches the temperature of the walls. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 62791
I've been a programmer for over 15 yrs. I'm still a programmer and I employ programmers in my company. Programmer output can vary (easily) by a factor of 10 from programmer to programmer. (This is documented BTW - see "Rapid Development") If you are an average or above programmer and you are *actually writing code*, your output is so incredibly high that overtime will almost always be unecessary. Also, average to above average programmers *love* to write code and would work extra hours just for the enjoyment if they didn't have families to go home to. One more thing. As an employer/business owner - we have no incentive or inherent desire for people to work unpaid overtime. We just need the work done to keep the business moving forward. If you can do your part in 10 hours/wk. great, if not then whatever it takes is what it takes. Ken "Nial Stewart" <nial@spamno.nialstewart.co.uk> wrote in message news:3fab93a1$0$12691$fa0fcedb@lovejoy.zen.co.uk... > > Phil Hays <SpamPostmaster@attbi.com> wrote in message > news:3FAA5342.B1F91A03@attbi.com... > > > The current law makes salaried people not get paid overtime. If you don't > think > > that is fair, you need to convince voters to elect people that will change > the > > laws. > > Surely all the law says is that if you sign a contract of employment > which say you don't get paid overtime, then you can't expect to get > paid for overtime? > > It's up to you whether you sign in the first place. > > ? > > > Nial > > > >Article: 62792
Petter Gustad wrote: > In SVF files generated by impact there will be delay statements on the > form: > > // Loading device with a 'ferase' instruction. > ... > RUNTEST 15000000 TCK; > > What is the minimum delay as a result of this statement, i.e. what is > the assumed TCK frequency for impact generated SVF files? > > TIA > Petter > In the Xilinx SVF file, the assumed TCK is the maximum TCK frequency of the device. Look the datasheet of the FPGA or your CPLD (between 10 to 40 MHz). Laurent www.amontec.com __________________________________ Q01 2004 -> Amontec will introduce a new USB JTAG POD based SVF ! ==================================Article: 62793
Philip, Funny, and appreciated. No, I did not file a case. I was designing standard cell logic.....not using DC for the FPGA. ASIC designers have exactly the same problems, and there is no solution in that space either. Austin Philip Freidin wrote: > On Thu, 06 Nov 2003 07:50:23 -0800, Austin Lesea <Austin.Lesea@xilinx.com> wrote: > >Morten, > > > >With the FROM:TO constraints I have always found them applying to things that > >I did not want them to. To really get the constraint "correct" (so that it > >didn't want to apply it to something else), I had to use FROM:THROUGH:TO > >(specify the path in question). > > > >After mucking about with this for a long time, and failing to get a > >reasonable result, I just pulled the constraints, and used the period > >constraint all alone. The multicycle through paths now did not meet timing > >(failed), but at least I could go and manually check each one, and "sign off" > >that these paths were OK none the less. > > Have you filed a case with the hotline? > > >The area was also massively affected by the FROM:THOUGH:TO constraints, with > >very poor timing results (worse than the period constraint alone) resulting > >on the paths that I really cared about and larger area..... > > Probably should file a case on this too. > > >I suppose that if I had a single clock things would have worked better, but > >with multiple clock domains, resynchonization circuits, and the rest of the > >stuff, the FROM:TO constraints just seemed to be causing me nothing but > >headaches. > > Maybe file a case on this? > > >(as the synthesizer just seemed to want to apply relaxed > >constraints to too many paths). > > ok, I'll shut up now. > > >Austin > > PhilipArticle: 62794
Rick, Not true at Xilinx. Closing a case that is unresolved with an unhappy customer is potentially grounds for disciplinary action. That is why I am the volunteer 'lightning rod' for such complaints. I am not interested in disciplining folks, but rather in improving the service that is offered (find the problem: fix it). Austin rickman wrote: > Just remember that support people get graded on how quickly they close > cases, not how "well" they close them (as least as far as I can tell). > And this is not limited to Altera. Speed is clearly the primary > evaluation of support at most companies. > > Joe Thompson wrote: > > > > I'm in the middle of a similar situation. I just reported a fatal, > > reproducible error on "My Support." Once the tech was able to > > reproduce the error, his response was that the bug would be "fixed in > > a future version..." Case closed. > > > > He also said that he successfully tested the design using the > > integrated FPGA Compiler II tool (I'm using Precision) and recommended > > that approach as a workaround. I tried it and found that my > > utilization jumped from ~75% with Precision to 116% with the > > integrated synthesis. > > > > Needless to say, I am not impressed. > > > > Joe > > ------------------------------------------------------------ > > Joe G. Thompson Phone: (603) 512-9003 > > joe@advancedprinciples.com Fax: (208) 730-5713 > > > > On 3 Nov 2003 01:05:37 -0800, rotemg@mysticom.com (Rotem Gazit) wrote: > > > > >Recently we decided to use Altera Cyclone part in a new design. When > > >we ran into problems I opened a web case using "Altera's my support". > > >After two days of silence I added an update explaining why the problem > > >is urgent. > > >After 10 days !!! I got the first response asking for the name of the > > >local FAE and providing no more information. > > >I answered the question and in exchange I got email saying "your > > >service request will be closed" . > > -- > > 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: 62795
Yu Jun, Knock off 20% for .13u from schematic to RC extracted. Also depends on what the foundry actually supports: is this based on lo-k dieletric? If not, that will take you down another 5%. The Virtex II Pro IBM405PPC runs at 450 MHz, so I would expect any well designed and semi-custom layout uP to be at least that fast in .13u. Austin Yu Jun wrote: > I'm working on a cpu core and intend to embed it into ASIC circuits, > with the aim to do some network processing. Now the FPGA prototype is > running and a 66M speed is achieved( xilinx virtexII-4 ). Wondering > how fast it can run in ASIC, we had our ASIC guys to synthesize the > codes and the result was shocking, it reached 400M! Far beyond our > expectation of 150M. The library we used was of 0.13u, from TI, fairly > fast, in which a NAND gate is around 0.03ns. > > Now my question is: Is the ASIC speed result reliable? Since we didn't > do P&R( we don't have tools and experiences ), I really doubt the > timing report may be over optimistically estimated and not reliable. I > was told something about "wire load model" and ours is automatically > selected by the compiler. > > Anybody can give me some hints or direct me to some documents will be > very appreciated! Thank you very much. > > yu jun > > yujun@huawei.comArticle: 62796
Francisco Rodriguez wrote: > As your numbers are 32-bit wide, and overflow condition is a flag > about the result of the _whole_ v := v + i operation, it can be determined > by the MSB bits only (that is, from columns 31 and 30 of the addition). Thank you! I think I used the wrong word "underflow". What I mean is: if "i" is negative, it might be that abs(lo(i)) is greater than lo(v). What happens then? An example: v = 1234 0100 hex i = 0000 0101 hex The operation for the lo bits will result in FFFF and the carry will be set. Then when I add the high bits, it will be 1235 when it should actually be 1233. How do I save that the first operation was not an overflow but a borrow? (I don't know how to call this. That's what I mistakenly called underflow). Glen Herrmannsfeld wrote: > After the high halfword add, you compare the carry out to the carry out of > the sign bit to the carry in of the sign bit. If they are different then it > is overflow or underflow. The value of such bit tells you which one. So does that mean I have to modify my architecture and set TWO flags? A carry flag and a negative flag (if sign of last operation was negative), and then the Add-With-Carry instruction would look at both? Thanks a lot!Article: 62797
Since this is the fpga newsgroup, not the ASIC folks.... Synchronous resets used directly in your design are great to use. The timing analysis knows when sync resets use synchronous resources. Using a synchronous signal to asynchronously reset is problematic but - after a few incorrect tries - you can probably apply proper constraints to make them work. Some FPGAs have dedicated set/reset resources that can be either synchronous or asynchronous. Other FPGAs have some of their logic configurations design to use a synchronous clear applicable in the particular configuration. Often adding a single additional input - in the form of the synchronous reset - keeps the logic within the LUT or LE that was originally produced. The performance reduction due to synchronous resets can be pretty minor - often not an issue. - John_H <se10110@yahoo.com> wrote in message news:96922c52.0311070357.7493b7c4@posting.google.com... > Hello, > > In a current FPGA-based design, I have a sub-block whose synchronous > outputs drive some logic such as counters & flip-flops(external to > the sub-block but internal to the FPGA). The current design has the > sub-block synchronously enabled when it needs to be used and > synchronously disabled when it does not need to be used. > > When the block is de-selected (going from enabled to disabled), I > would like the sub-block's flip-flops to be reset, so the next time > the block is enabled, the outputs are in a known state. > > My question: > > Is it safe to use a synchronous reset signal which is high for one > system clock cycle to drive the async reset on the flip-flops of my > sub-block? > > Note: The sub-block flip-flops are synchronously disabled before being > reset by the synchronous reset signal, so I am not creating a > setup/hold time problem with the sub-block FFs. > > My real concern is about violating the setup & hold time on the > flip-flops the sub-block drives. My thinking is that even though the > reset signal is synchronous, the sync. reset signal will probably not > be distributed via a low-skew line (aka global signal) and I could > potentially have a far sub-block flip-flop not reset by the time the > clock comes around, and thus I clober a flip-flop which is driven by a > s-b FF. > > If driving the async. reset on the FFs is a bad idea, my other > approach was to take each DFF of the sub-block and update it to > include a 2-input AND gate on the input. One input to the AND2 gets > the original D-input signal while the second input gets a NOTed > SCLR(active high), so I create a synchronous clearable DFF. > > I would appreciate comments, suggestions, etc. > > JayArticle: 62798
Hello, I recently release Confluence 0.7.3. The big addition is the ability to instantiate custom Verilog and VHDL modules from with in Confluence. This feature is especially useful for instantiating FPGA specific blocks with configurable constraints (timing, RLOC, etc.). Both sequential and combinatorial modules are supported, and modules may include any number of configuration parameters. You can also create C and Python models for your external components to integrate with Confluence generated C and Python for simulation. Installation is easier too. Just extract the tarball (_.tar.gz), set an environment variable, update the path, and your done. I also removed license protection. Like most tool users, I hate dealing with LM. So Confluence is now on the honor system. My licensing policy still stands: free for personal and academic use, and 1 free seat per company for commercial endeavors. Companies can also install any number of copies for evaluation. Download at: http://www.launchbird.com/download.html Confluence runs on Linux (x86), Cygwin (windows), and Solaris. Regards, Tom -- Tom Hawkins Launchbird Design Systems, Inc. 952-200-3790 http://www.launchbird.com/Article: 62799
se10110@yahoo.com wrote: > My real concern is about violating the setup & hold time on the > flip-flops the sub-block drives. My thinking is that even though the > reset signal is synchronous, the sync. reset signal will probably not > be distributed via a low-skew line True. You wouldn't want to waste one for a single connection. > If driving the async. reset on the FFs is a bad idea, my other > approach was to take each DFF of the sub-block and update it to > include a 2-input AND gate on the input. One input to the AND2 gets > the original D-input signal while the second input gets a NOTed > SCLR(active high), so I create a synchronous clearable DFF. Yes. Do that. -- Mike Treseler
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