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
hi all I am wondering if it is feasible for OPB to connect microblaze and BRAMS. For instance, OPB connects one microblaze and 2 64KB BRAMS (with different address map). Each BRAM is instruction/data dual port. So programmer may consider the system has 128 KB memory space. How do you find this scheme? Are there any other things to consider? thankyou for replyArticle: 79376
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:111a90slp3cc98a@corp.supernews.com... > Hello Group, > > Thank you all for the help with my last question. > > I have another issue with the Behaviour vs. PAR > models as it relates to FIFOs. I find that in the > behavior model the read cycle looks as if it takes > two clock cycles to get new data and in the PAR > model the data comes more readily, around 11ns, > about half a cycle. > > I suspect that the Behavior model might be two > cycles delay since the Read_Enable sets up on > a rising edge of a clock. However the read cycle > does not initiate until one cycle later, when the > Read_Enable is high, albeit going low. And then > there is one more clock delay in the read output. If the design is synchronous, and the design is fully constrained from a timing perspective, it is my expectation and experience that the RTL (behavior) simulations will match the post place and route back-annotated simulations on a clock cycle to cycle basis. If they do not, then either the stimulus from the testbench does not consistently meet the set-up and hold times for the two representations of the design, or the design is not being synthesized/implemented as desired and you have to go in and figure out why. Figuring out why an RTL simulation does not match a fully implemented back-annotated simulation is not a happy place to be and I think it is wise to develop a style where you minimize the amount of time one spends in the unhappy place. It is important to not ignore that unhappy place, because a more unhappy place is having to probe hardware with a scope to figure out why a design is not working as expected, and explain to others why the hardware is not working yet. -- just my 2 cents Newman > > If I were modeling this on the top level I would > delay my clock a tad, so the read enable was > already set up, and then the output would come > one cycle later, not two. Unfortunetely, this is > an instantiated component in a lower level, > wherein the read enable is generated by the > same clock that runs the FIFO. I guess this > is the problem of infinitely fine timing units > called deltas? > > It would be an ugly and time consuming process > to run everything through the PAR and post sim. > I suppose I could run a separate clock, down the > hierarchy to run just the FIFO, for simulation > purposes. But I am hoping that this group knows > a better solution. > > Thanks, > > Brad Smallridge > b r a d @ a i v i s i o n . c o m > > > > > > > > > > >Article: 79377
Thankyou Jon and John for reply I have another question. In case we have SMP implementation of the dual microblazes and we have no OS, the problem is application writing methodology. I have no idea --: If you have experience on programming on SMP in fpga, how did you manage that?Article: 79378
Austin, Nice bafflegab. 1. I have the spec for the dielectric and conductor stack for the 90 nm process we're using in front of me. I wrote field solvers for my Master's degree and commercially before I saw the light and switched to FPGAs for my PhD. So I really don't need an "ICDES expert" to explain metal stacks or RC extraction to me. 2. The metal stack is dominated by low-K. 3. Lateral capacitance is reduced by low-K, since you use low-K between the wires on a layer. Since lateral capacitance dominates in deep submicron (e.g. 90 nm), without doing this, low-K would be fairly pointless. 4. Having "regular k" between metal 1 and the substrate still means even metal 1 gains most of the benefit of low-K, since sidewall (lateral) capacitance dominates, and you use low-K between the metal1 wires. Plus you reduce the (smaller) capacitance to metal 2. 5. Metal resistance does not impact power. You can prove this fairly simply mathematically. 6. Metal resistance impacts speed, although not that much in FPGAs since the wires are rebuffered so often. However, since delay = RC (lumped approximation), that pesky C is still in there and reducing it gives you a linear speedup on the distributed RC delay of the metal wires. 7. The simulations showing what we got from low-K vs. high-K were detailed, and agreed with measured data from the sample chips we ran (yes, we run chips on different variants of the process too). Vaughn Betz Altera [v b e t z (at) altera.com] "Austin Lesea" <austin@xilinx.com> wrote in message news:cv2h98$bai2@cliff.xsj.xilinx.com... > Vaughn, > > Well, you certainly have been fooled. > > See below, > > Austin > > Vaughn Betz wrote: >> "Austin Lesea" <austin@xilinx.com> wrote in message >> news:cuvptt$baj6@cliff.xsj.xilinx.com... >> >>>Vaugn, >>> >>>Shell and pea game: no, you do not get the entire benefit of reduced C. >> >> >> The entire benefit would be 19% speed and dynamic power reduction. As I >> said, we get about 2/3 of that maximum benefit, since not all C is metal >> C, but most is. >> >>>Also, not all layer dielectrics are Lo-K. For example, the clock tree is >>>near the top, where regular dielectric is used, isn't it? >> >> >> We use low-k to near the top of the metal stack. At the very top, where >> you're routing power and ground, you don't need (or even want it), since >> high capacitance on power and ground is beneficial (helps prevent ground >> bounce & vcc sag). The vast majority of the switching capacitance >> (clocks, routing, ALMs, MACs, etc.) is in metal surrounded by low-k. > > I doubt it. The dielectric above the transistors is regular undoped glass > (SiO2). K = 4.3. Then comes the lo-K after M1. M1 through M5 is all > they can do as lo-K, if they do more, it sufffers major yield and > reliability issues. Of maybe you haven't noticed the delamination yet? >> >> >>>At least, we evaluated both with, and without Lo-K devices (from the same >>>masks and fab), and were surprised to see only a 5% improvement. >>> >>>Did you do the same experiment? We were surprised. >> >> >> We simulated everything with and without low-K, and got the ~13% >> improvement > > Nope. You did not. If you did, you would discover that the layer above > the transistors and below metal 1, as well as the upper layers for clocks, > etc. leads to less than expected improvements. I am pretty sure your > ICDES folks just scaled everything. It would be a major project to > develop, and QC spice models for both processes, and I seriously doubt > anyone would bother. > > >> I previously mentioned. I am also surprised you got only 5%. That is >> certainly well below mainstream for the industry -- if everyone were >> seeing such small gains, > > which they are. > > I doubt the fabs and semiconductor equipment vendors would >> be pumping billions into developing low-k (and next generation >> extra-low-k) dielectrics. > > The only folks making money on this are the equipment suppliers. No one I > know asked for it. Yes, it can be a major benefit to ASIC, uP, and > perhaps memories. But, it just isn't doing anything for us. Now, we will > get lo-K for free, as they have the equipment and process now, butguess > what? We still do not see more than a 5% improvement from V4 without lo-K > to V4 with lo-K. Wow, two generations and two sets of side by side lo-K > and regular experiments. > > Ignorance I guess is bliss. > > > Sounds like you may have used low-k for only a few metal >> layers, so perhaps that explains your disappointing experience. > > Nope,as I described, the only layers alloed to be lo-K for lifetime > delamination issues and quality are the ones above M1, and below M5. > Anymore than that, and we have see problems with fab process qual (not on > our parts, but their test structures). > >> >> >>>Turns out, there is a lot more in the equations that just C. >>> >>>If it was just that simple, extracted simulations in spice would be >>>unneeded. >> >> >> This is backwards. As metal capacitance has become the dominant >> capacitance, extracting layouts to obtain all the metal parasitics before >> running SPICE has become essential to getting accurate answers. Go back >> enough process generations and this was less true -- you could write up >> your transistor-level schematic in a SPICE deck, simulate it with no >> thought of metal, and you wouldn't be that far off for most circuits, >> since transistor parasitics dominated. Now that metal dominates, you >> have to extract layouts to get the metal C or you get bad answers. > > I can see you really have no clue about where the wire models are going. > How thick is the metal, how thick is the dielectric? How close are the > wires? There is R there (and lots of it). There is C there, too. There > is also side wall C (the sidewalls are regular FSG, or SiO2 -- no lo-K > advantage). > > Again, you go back and ask if they actually had foundry models for with, > and without, and what the actual stack up was. One of the biggest > overstatements we have seen recently is all of this nonsense about the > superiority of lo-K. > > Its nice, don't get me wrong, but don't tout it as a miracle if you have > never proven it is. You don't know. We do. > > Take the time to do it right, or at least study it right. Get an ICDES > wire model expert to talk to you about where the lo-K is, and isn't. > >> >> Vaughn Betz >> Altera >> [v b e t z (at) altera.com] >>Article: 79379
Peter, Pass transistors are timing critical in FPGAs. Using a thicker oxide reduces Cox, and transistor drive strength is linearly proportional to Cox. Much like increasing Vt, you can control leakage, but there is a speed cost to be paid. Otherwise I agree with everything you said though! Vaughn Betz Altera [v b e t z (at) altera.com] "Peter Alfke" <peter@xilinx.com> wrote in message news:1108669563.714735.314660@f14g2000cwb.googlegroups.com... >I hope everybody here realizes that there is no trade-off between > triple gate oxide and low-k dielectric. They reside on different > "floors" of the vertical IC structure. > > The availability of a third oxide thickness at the transistor level > (ground floor) gives the designer the freedom to reduce leakage current > in pass transistors (where it does not affect speed) and in > configuration memory, where lower speed is actually desirable. We at > Xilinx think it is a great tool to reduce leakage current without any > performance loss, specially in FPGAs where certain (millions of) > transistors would benefit from being slow. > > Low K dielectric (at the upper floors) hasnothing to do with the > transistors, since it is used only in the layers of interconnect well > above the transistors. It is obviously desirable to lower parasitic > capacitance, as long as it can be done with good yield and without loss > of reliability. Different foundries have different approaches and > different attitudes. > > Thicker high-K dielectric in the gate oxide (ground floor) would > actually be desirable, since it would reduce gate leakage current, but > it does not seem to be a mature process yet ( I have been told. I'm not > an expert). > > We are all chasing the holy grail of high performance at low (or at > least reasonable) static and dynamic power consumption. > > Peter Alfke >Article: 79380
Hi, You can have as many BRAM memory blocks (up to the limit of your FPGA) on LMB and OPB. One the LMB, just create two bram blocks and four lmb bram controllers and two lmb busses. One the OPB, you can either have one OPB bus with two opb bram controller. This is a now a shared bus between instruction and data side of MicroBlaze. IF you want more speed you can create two OPB busses and do the same as for the LMB. All this is very easy to do in the XPS tool. I would go for the LMB since it has lower latency for memory access than the OPB. Göran Jack wrote: > hi all > > I am wondering if it is feasible for OPB to connect microblaze and > BRAMS. > > For instance, OPB connects one microblaze and 2 64KB BRAMS (with > different address map). Each BRAM is instruction/data dual port. So > programmer may consider the system has 128 KB memory space. > > How do you find this scheme? Are there any other things to consider? > > thankyou for reply >Article: 79381
If you are VERY certain that your Xilinx FPGA is defective, you can ask your distributer (if you bought the FPGA from an authorized source) to start a process called RMA, where you are requested to answer a number of questions and are eventually (if you qualify) given an account number to send in the defective device to. Xilinx will then inspect and E-test the device to find out what went wrong. As said, normally you would expect defective I/O from ESD damage and I don't know if that would qualify, but if you encounter an internal error that can be attributed to a logic cell, it might. Good luck! /LarsArticle: 79382
Can anyone tell me embedding of SUBJ? I've tried a lot of methods(recommendations in G.704(1998&1995); i've read the theory of CRC calculating and made some entities but CRC from my E1 tester doesn't match with mine. I've tried another tester - no changes).Article: 79383
On 18 Feb 2005 00:47:18 -0800, kefir_@mail.ru (kefir) wrote: >Can anyone tell me embedding of SUBJ? I've tried a lot of >methods(recommendations in G.704(1998&1995); i've read the theory of >CRC calculating and made some entities but CRC from my E1 tester >doesn't match with mine. I've tried another tester - no changes). There's nothing wrong with the G.704 specification, and there's nothing wrong with the E1 testers. You have a bug. You might need to tell us something about your implementation before we can help. Regards, AllanArticle: 79384
> http://toolbox.xilinx.com/docsan/2_1i/data/common/jtg/fig26.htm > I build one according to this schematic and it works well with XC95144XL. thank you for your experience sharing. Do you know which version this cable is? (II, III, IV ?) Does it make some difference in IMPACT?Article: 79385
Hi John, I was able to both convert to pdf and to send directly to the printer=20 from the printing wizard in ChipScope. I've installed service pack 3 for = ChipScope 6.3, I don't know if that has anything to do with it... Might=20 be worth a try if you havn't. I can email you some of my waveforms as pdf:s if that makes you happier..= =3D) /Johan John Williams wrote: > Hi, >=20 > I'm trying to print a waveform from ChipScope Pro 6.3 under Windows. >=20 > I have a waveform window open, and a printer selected, however when I=20 > try to select the "Print" option from the File menu, nothing happens.=20 > It's quite strange - after the mouse hovers on the "Print" menu item fo= r=20 > about a quarter of a second, a small gray square (maybe 3x3 pixels?)=20 > appears next to it. No amount of clicking can cause the Print wizard = > to launch. >=20 > Anyone seen this and know a workaround? >=20 > Thanks, >=20 > John >=20 --=20 ----------------------------------------------- Johan Bernsp=E5ng, xjohbex@xfoix.se Research engineer Swedish Defence Research Agency - FOI Division of Command & Control Systems Department of Electronic Warfare Systems www.foi.se Please remove the x's in the email address if replying to me personally. -----------------------------------------------Article: 79386
517433341
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:82db119jglou13ll7t8b7v62bqs5el5ugh@4ax.com...
> On 18 Feb 2005 00:47:18 -0800, kefir_@mail.ru (kefir) wrote:
>
>>Can anyone tell me embedding of SUBJ? I've tried a lot of
>>methods(recommendations in G.704(1998&1995); i've read the theory of
>>CRC calculating and made some entities but CRC from my E1 tester
>>doesn't match with mine. I've tried another tester - no changes).
>
> There's nothing wrong with the G.704 specification, and there's
> nothing wrong with the E1 testers.
>
> You have a bug.
>
> You might need to tell us something about your implementation before
> we can help.
>
> Regards,
> Allan
I know :) But there is also the G.706 recommendnation and there is
another algorithm. there is {CRC computed by G.704} XORed with {CRC
computed with Sa4(new) bits XORed with Sa4(previous) bits}.
i've also tried to divide the initial SMF(with C bits set to
zero)complemented with 4 zero bits by the 10011 polynom using XOR
rules and insert the residue of division into C bits as shown in
G.704.
I've tried to use the scheme shown at page 33 FIGURE A.33/G.704.
i didn't foget to reset triggers after SMF and set C bits to zero when
fed it to this scheme.
Article: 79387517433341 "Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:82db119jglou13ll7t8b7v62bqs5el5ugh@4ax.com... > On 18 Feb 2005 00:47:18 -0800, kefir_@mail.ru (kefir) wrote: > >>Can anyone tell me embedding of SUBJ? I've tried a lot of >>methods(recommendations in G.704(1998&1995); i've read the theory of >>CRC calculating and made some entities but CRC from my E1 tester >>doesn't match with mine. I've tried another tester - no changes). > > There's nothing wrong with the G.704 specification, and there's > nothing wrong with the E1 testers. > > You have a bug. > > You might need to tell us something about your implementation before > we can help. > > Regards, > Allan can you place a verilog or any HDL text(or schematic as a picture) realizing the CRC4 algorithm?Article: 79388
On Fri, 18 Feb 2005 14:33:36 +0300, "Michael Polovykh"
<kefir@rissa.ru> wrote:
>517433341
>"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
>message news:82db119jglou13ll7t8b7v62bqs5el5ugh@4ax.com...
>> On 18 Feb 2005 00:47:18 -0800, kefir_@mail.ru (kefir) wrote:
>>
>>>Can anyone tell me embedding of SUBJ? I've tried a lot of
>>>methods(recommendations in G.704(1998&1995); i've read the theory of
>>>CRC calculating and made some entities but CRC from my E1 tester
>>>doesn't match with mine. I've tried another tester - no changes).
>>
>> There's nothing wrong with the G.704 specification, and there's
>> nothing wrong with the E1 testers.
>>
>> You have a bug.
>>
>> You might need to tell us something about your implementation before
>> we can help.
>>
>> Regards,
>> Allan
>I know :) But there is also the G.706 recommendnation and there is
>another algorithm. there is {CRC computed by G.704} XORed with {CRC
>computed with Sa4(new) bits XORed with Sa4(previous) bits}.
>
>i've also tried to divide the initial SMF(with C bits set to
>zero)complemented with 4 zero bits by the 10011 polynom using XOR
>rules and insert the residue of division into C bits as shown in
>G.704.
>
>I've tried to use the scheme shown at page 33 FIGURE A.33/G.704.
>i didn't foget to reset triggers after SMF and set C bits to zero when
>fed it to this scheme.
A useful technique is to work through the algorithm on paper (or a
spreadsheet, etc.). That way, you separate your understanding of the
algorithm from any bugs you might have in your implementation.
It's only a 4 bit CRC, so it shouldn't take to long to do by hand.
(See this recent c.a.f thread for an example:
http://groups-beta.google.com/group/comp.dcom.sdh-sonet/browse_frm/thread/972c354699ba8391
)
Regards,
Allan
Article: 79389Hi all, I hope that some of you that are writing code for the microblaze be able to help with the following question: Normally C stractures are aligned on a 4 byte addresses boundaries. But usually in communication application there is a need to parse messages buffers with fields that are aligned on a single byte basis. I know on other CPUs that there is a #pragma commands that allow a definition of structures as "packed". Does anyone knows how to define packed structures on Microblaze C compiler? and if so can you provide an example? Thanks in advance, Moti.Article: 79390
517433341
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:8klb11hi4jqsnkaci10im0s5ih31tm8at8@4ax.com...
> On Fri, 18 Feb 2005 14:33:36 +0300, "Michael Polovykh"
> <kefir@rissa.ru> wrote:
>
>>517433341
>>"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
>>message news:82db119jglou13ll7t8b7v62bqs5el5ugh@4ax.com...
>>> On 18 Feb 2005 00:47:18 -0800, kefir_@mail.ru (kefir) wrote:
>>>
>>>>Can anyone tell me embedding of SUBJ? I've tried a lot of
>>>>methods(recommendations in G.704(1998&1995); i've read the theory of
>>>>CRC calculating and made some entities but CRC from my E1 tester
>>>>doesn't match with mine. I've tried another tester - no changes).
>>>
>>> There's nothing wrong with the G.704 specification, and there's
>>> nothing wrong with the E1 testers.
>>>
>>> You have a bug.
>>>
>>> You might need to tell us something about your implementation before
>>> we can help.
>>>
>>> Regards,
>>> Allan
>>I know :) But there is also the G.706 recommendnation and there is
>>another algorithm. there is {CRC computed by G.704} XORed with {CRC
>>computed with Sa4(new) bits XORed with Sa4(previous) bits}.
>>
>>i've also tried to divide the initial SMF(with C bits set to
>>zero)complemented with 4 zero bits by the 10011 polynom using XOR
>>rules and insert the residue of division into C bits as shown in
>>G.704.
>>
>>I've tried to use the scheme shown at page 33 FIGURE A.33/G.704.
>>i didn't foget to reset triggers after SMF and set C bits to zero when
>>fed it to this scheme.
>
> A useful technique is to work through the algorithm on paper (or a
> spreadsheet, etc.). That way, you separate your understanding of the
> algorithm from any bugs you might have in your implementation.
> It's only a 4 bit CRC, so it shouldn't take to long to do by hand.
>
> (See this recent c.a.f thread for an example:
> http://groups-beta.google.com/group/comp.dcom.sdh-sonet/browse_frm/thread/972c354699ba8391
> )
>
> Regards,
> Allan
Where can I take the shot bit consecution with true crc4 to compare with CRC
computed by myself?
Article: 79391Shift register example? Hi I am looking for a parallel in serial out latching shift register in VHDL. I want 16 bits but any example would be appreciated. ThanksArticle: 79392
Dear everybody, the goal of my post is to collect your opinions about the use of Altera Cyclone devices in a rugged environment. I have to design a board which should control a chopper based on GTOs. The environment is a railway vehicle and the following are the conditions I have to consider: - extreme temperature range (-40°C to +85°C) - strong mechanical vibrations - long life duration (> 25 years) - high degree of reliability - very low frequency of maintenance From the point of view of the design I think Altera Cyclone is the best choise for this kind of project beacuse its high flexibility. But I have some doubts about its functionality in a rugged environment like above. Did you experience the use of Altera Cyclone in a rugged environment ? What are your opinions about my choise ? Best Regards /Alessandro StrazzeroArticle: 79393
I have designed a slave OPB peripheral, simulated with VCS to check for
the correct functionality and imported it into EDK. All was fine.
In EDK, when generating the netlist, the HDL code is synthesized using
XST (Xilinx Synthesis Tool), so that the netlist can be generated.
The problem I'm having is that there is an "inout" port in my user logic
that should go/come all the way up to/from the top level but for some
reason, when XST generates an HDL wrapper to my user logic, it expects
my sub-module to have 1 input and 2 output ports (see the error below)
instead of just the one inout port, as if I had to use directly the
input/outputs of an IOBUF instead of just one inout, e.g.:
// this is just an example:
IOBUF txrx
(
.I ( TXRX_IO_I ), // input
.IO ( TXRX_IO ), // inout
.O ( TXRX_IO_O ), // output
.T ( TXRX_IO_T ) // ouput enable
);
In my code I have something like this:
// port declaration
inout TXRX_IO;
assign TXRX_IO = TxEn? 1'bz:0; // output, pull up assumed
if (CanRead)
Read_reg <= TXRX_IO; // input
This is a very simple and elegant Verilog code that infers a tristate
buffer. Surely I should not have to change my design to use the 3 extra
ports instead of just the one inout.
Also, in my *.mhs file I clearly stated that it should be an external port:
# Global Ports
PORT TXRX_IO = txrx, DIR = IO # txrx connects to the peripheral's
# TXRX_IO port
If you have any clues about how this can be solved, I'll appreciate if
you could post them in here. Many thanks.
TonyF
XST error message:
------------------------------------------------
Running XST synthesis ...
INFO:MDT - The following instances are synthesized with XST. The MPD
option IMP_NETLIST=TRUE indicates that a NGC file is to be produced
using XST synthesis. IMP_NETLIST=FALSE (default) instances are not
synthesized. A batch file, synthesis.sh, has been created that allows
you to synthesize those instances in your specified synthesis tool of
choice.
opb_txrx_0_wrapper (opb_txrx_0) -
C:\EDK_examples\v2pro_eval_mgt2\system.mhs:397 - Running XST synthesis
ERROR:HDLCompilers:91 - ../hdl/opb_txrx_0_wrapper.v line 64 Module
'opb_txrx' does not have a port named 'TXRX_IO_I'
ERROR:HDLCompilers:91 - ../hdl/opb_txrx_0_wrapper.v line 65 Module
'opb_txrx' does not have a port named 'TXRX_IO_O'
ERROR:HDLCompilers:91 - ../hdl/opb_txrx_0_wrapper.v line 66 Module
'opb_txrx' does not have a port named 'TXRX_IO_T'
ERROR:MDT - HDL synthesis failed!
Article: 79394"Alessandro Strazzero" <alessandro.strazzero@virgilio.it> wrote in message news:391fed46.0502180459.5ad267fb@posting.google.com... > Dear everybody, > > the goal of my post is to collect your opinions about the use of Altera > Cyclone > devices in a rugged environment. I have to design a board which should > control > a chopper based on GTOs. The environment is a railway vehicle and the > following > are the conditions I have to consider: > > - extreme temperature range (-40°C to +85°C) > - strong mechanical vibrations > - long life duration (> 25 years) > - high degree of reliability > - very low frequency of maintenance > > From the point of view of the design I think Altera Cyclone is the best > choise > for this kind of project beacuse its high flexibility. But I have some > doubts > about its functionality in a rugged environment like above. > > Did you experience the use of Altera Cyclone in a rugged environment ? > What are your opinions about my choise ? > > Best Regards > > /Alessandro Strazzero I think the Cyclone would be an excellent candidate. I know its being used in the Oil&Gas industry in down hole tools. This is a far more extreme environment than you're describing. Of course there is no 25 year history. KenArticle: 79395
I want to simulate the GT_CUSTOM swift model under VCS. According to
Xilinx the following VCS versions are qualified under Linux (ISE 6.3i)
Linux (redhat 7.3 / 8.0) = VCS 7.0 2002.12.r16(scirocco)
Linux Enterprise Edition V3.0 = VCS_MX7.1.R22
The problem with 7.0 is that I have an encrypted verification
environment which appears to run under VCS 7.1.1L1 and VCS7.1.2.
(these run under AMD64 as well). Also, it appears that VCS_MX7.1.1R22
is not a customer release (I hope the corresponding VCS version works
since my design is Verilog only so I don't need the MX/VHDL part).
So, anybody else using the GT_CUSTOM swift model with VCS under Linux
on post VCS 7.0 out there?
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Article: 79396"Alessandro Strazzero" <alessandro.strazzero@virgilio.it> wrote in message news:391fed46.0502180459.5ad267fb@posting.google.com... > Dear everybody, > > the goal of my post is to collect your opinions about the use of Altera > Cyclone > devices in a rugged environment. I have to design a board which should > control > a chopper based on GTOs. The environment is a railway vehicle and the > following > are the conditions I have to consider: > > - extreme temperature range (-40°C to +85°C) > - strong mechanical vibrations > - long life duration (> 25 years) > - high degree of reliability > - very low frequency of maintenance > > From the point of view of the design I think Altera Cyclone is the best > choise > for this kind of project beacuse its high flexibility. But I have some > doubts > about its functionality in a rugged environment like above. > > Did you experience the use of Altera Cyclone in a rugged environment ? > What are your opinions about my choise ? > > Best Regards > > /Alessandro Strazzero Alessandro , We're using it in the gate drive of a high performance IGBT drive. The mechanical/thermal environment isn't too bad, but the EMC environment is pretty tough. We have had no problems. GaryArticle: 79397
Thanks glen for the response, but what about making the program stop completely and pop up a message that says something like "ERROR", is there a way to implement that? I have tried using "disable" but that won't compile, I think it was unsupported or something. Thanks, AnnArticle: 79398
"Thomas" <tb_news@arcor.de> wrote in message news:9149a016.0502090251.788ddae6@posting.google.com... > "John_H" <johnhandwork@mail.com> wrote in message news:<DH5Od.6$iV.232@news-west.eli.net>... > > TIMEGRP MyInputs OFFSET = IN 2 ns VALID 7 ns BEFORE MyClk; > > > > "Thomas" <tb_news@arcor.de> wrote in message > > news:9149a016.0502080528.7bee2cad@posting.google.com... > > > Hi all, > > > > > > I have a signal that is valid 2 ns before the active clock edge > > > and stays valid until 5 ns after the active clock edge. > > > Is there a possibilty to put this constraint into > > > the ucf file? > > > > > > any hints are welcome > > > > > > Thomas > > thanks > although I cannot meet the spec, > up to now :( If you cannot meet the setup time, register the input in the IOB will probably help. HTH, Jim jimwu88NOOOSPAM@yahoo.com (remove capital letters) http://www.geocities.com/jimwu88/chipsArticle: 79399
"AL" <ann.lai@analog.com> wrote in message news:ee8bf07.1@webx.sUN8CHnE... > Thanks glen for the response, but what about making the program stop completely and pop up a message that says something like "ERROR", is there a way to implement that? I have tried using "disable" but that won't compile, I think it was unsupported or something. Thanks, Ann What program? Verilog describes the layout of hardware. I suppose you could connect all of your I/O pins to ground (or use tri-state and disconnect them), but you can't stop electrons moving in the wires! Alun Harford
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