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 8/1/13 5:56 AM, RCIngham wrote:
>>> On 7/31/13 9:36 AM, RCIngham wrote:
>>>> [snip]
>>>>>
>>>> Unless 'length' is limited, your worst case has header
>> "0000001111111111"
>>>> (with an extra bit stuffed) followed by 16 * 1023 = 16368 zeros,
which
>> will
>>>> have 2728 ones stuffed into them. Total line packet length is 19113
>>>> symbols. If the clocks are within 1/19114 of each other, the same
number
>> of
>>>> symbols will be received as sent, ASSUMING no jitter. You can't
assume
>>>> that, but if there is 'not much' jitter then perhaps 1/100k will be
>> good
>>>> enough for relative drift to not need to be corrected for.
>>>>
>>>> So, for version 1, use the 'sync' to establish the start of frame and
>> the
>>>> sampling point, simulate the 'Rx fast' and 'Rx slow' cases in
parallel,
>> and
>>>> see whether it works.
>>>>
>>>> BTW, this is off-topic for C.A.F., as it is a system design problem
not
>>>> related to the implementation method.
>>>>
>>>>
>>>
>>> Since you can resynchronize your sampling clock on each transition
>>> received, you only need to "hold lock" for the maximum time between
>>> transitions, which is 7 bit times. This would mean that if you have a
>>> nominal 4x clock, some sample points will be only 3 clocks apart (if
you
>>> are slow) or some will be 5 clocks apart (if you are fast), while most
>>> will be 4 clock apart. This is the reason for the 1 bit stuffing.
>>>
>>
>> The bit-stuffing in long sequences of zeroes is almost certainly there
to
>> facilitate a conventional clock recovery method, which I am proposing
not
>> using PROVIDED THAT the clocks at each end are within a sufficiently
tight
>> tolerance. Detect the ones in the as-sent stream first, then decide
which
>> are due to bit-stuffing, and remove them.
>>
>> Deciding how tight a tolerance is 'sufficiently tight' is probably
>> non-trivial, so I won't be doing it for free.
>>
>>
>
>Since a 4x clock allows for a 25% data period correction, and we will
>get an opportunity to do so every 7 data periods, we can tolerate about
>a 25/7 ~ 3% error in clock frequency. (To get a more exact value we will
>need to know details like jitter and sampling apertures, but this gives
>us a good ball-park figure). Higher sampling rates can about double
>this, the key is we need to be able to know which direction the error is
>in, so we need to be less than a 50% of a data period error including
>the variation within a sample clock.
>
>To try to gather the data without resynchronizing VASTLY decreases your
>tolerance for clock errors as you need to stay within a clock cycle over
>the entire message.
>
>The protocol, with its 3 one preamble, does seem like there may have
>been some effort to enable the use of a PLL to generate the data
>sampling clock, which may have been the original method. This does have
>the advantage the the data clock out of the sampler is more regular (not
>having the sudden jumps from the resyncronizing), and getting a set a
>burst of 1s helps the PLL to get a bit more centered on the data. My
>experience though is that with FPGAs (as would be on topic for this
>group), this sort of PLL synchronism is not normally used, but
>oversampling clocks with phase correction is fairly standard.
>
Some form of clock recovery is essential for continuous ('synchronous')
data streams. It is not required for 'sufficiently short' asynchronous data
bursts, the classic example of which is RS-232. What I am suggesting is
that the OP determines - using simulation - whether these frames are too
long given the relative clock tolerances for a system design without clock
recovery.
As I previously noted, this is first a 'system design' problem. Only after
that has been completed does it become an 'FPGA design' problem.
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 155676Vivek Menon <vivek.menon79@gmail.com> writes: > I have my SOPC_KIT_NIOS2 path set to C:\altera\80\nios2eds > > Any suggestions?? Clearly make isn't found. Look for make.exe under C:\altera and check what directories you have in your PATH.Article: 155677
Anssi Saari <as@sci.fi> wrote: > Vivek Menon <vivek.menon79@gmail.com> writes: > > > I have my SOPC_KIT_NIOS2 path set to C:\altera\80\nios2eds > > > > Any suggestions?? > > Clearly make isn't found. Look for make.exe under C:\altera and check > what directories you have in your PATH. make was found, but it couldn't run /bin/sh.exe (I think it's using cygwin). Check your PATH, and otherwise I'd reinstall the tools as something is obviously wrong in the cygwin install it's using. You don't have cygwin elsewhere on the machine do you? Are you running these from the GUI or from the shell? TheoArticle: 155678
On 8/2/2013 3:49 AM, alb wrote: > On 02/08/2013 06:19, rickman wrote: > [] >>> >>> This is what I meant indeed. I believe I confused DPLL with ADPLL... >> >> I am not familiar with ADPLL. What is that? > > It is an All Digital PLL: > > http://www.aicdesign.org/2003%20PLL%20Slides/L050-ADPLLs-2UP(9_1_03).pdf > > all the elements of a PLL are implemented in the digital domain. I guess I wasn't aware that a digital PLL wasn't *all* digital. That is what I have been referring to as digital. -- RickArticle: 155679
On 8/2/2013 6:35 AM, RCIngham wrote:
>> On 8/1/13 5:56 AM, RCIngham wrote:
>>>> On 7/31/13 9:36 AM, RCIngham wrote:
>>>>> [snip]
>>>>>>
>>>>> Unless 'length' is limited, your worst case has header
>>> "0000001111111111"
>>>>> (with an extra bit stuffed) followed by 16 * 1023 = 16368 zeros,
> which
>>> will
>>>>> have 2728 ones stuffed into them. Total line packet length is 19113
>>>>> symbols. If the clocks are within 1/19114 of each other, the same
> number
>>> of
>>>>> symbols will be received as sent, ASSUMING no jitter. You can't
> assume
>>>>> that, but if there is 'not much' jitter then perhaps 1/100k will be
>>> good
>>>>> enough for relative drift to not need to be corrected for.
>>>>>
>>>>> So, for version 1, use the 'sync' to establish the start of frame and
>>> the
>>>>> sampling point, simulate the 'Rx fast' and 'Rx slow' cases in
> parallel,
>>> and
>>>>> see whether it works.
>>>>>
>>>>> BTW, this is off-topic for C.A.F., as it is a system design problem
> not
>>>>> related to the implementation method.
>>>>>
>>>>>
>>>>
>>>> Since you can resynchronize your sampling clock on each transition
>>>> received, you only need to "hold lock" for the maximum time between
>>>> transitions, which is 7 bit times. This would mean that if you have a
>>>> nominal 4x clock, some sample points will be only 3 clocks apart (if
> you
>>>> are slow) or some will be 5 clocks apart (if you are fast), while most
>>>> will be 4 clock apart. This is the reason for the 1 bit stuffing.
>>>>
>>>
>>> The bit-stuffing in long sequences of zeroes is almost certainly there
> to
>>> facilitate a conventional clock recovery method, which I am proposing
> not
>>> using PROVIDED THAT the clocks at each end are within a sufficiently
> tight
>>> tolerance. Detect the ones in the as-sent stream first, then decide
> which
>>> are due to bit-stuffing, and remove them.
>>>
>>> Deciding how tight a tolerance is 'sufficiently tight' is probably
>>> non-trivial, so I won't be doing it for free.
>>>
>>>
>>
>> Since a 4x clock allows for a 25% data period correction, and we will
>> get an opportunity to do so every 7 data periods, we can tolerate about
>> a 25/7 ~ 3% error in clock frequency. (To get a more exact value we will
>> need to know details like jitter and sampling apertures, but this gives
>> us a good ball-park figure). Higher sampling rates can about double
>> this, the key is we need to be able to know which direction the error is
>> in, so we need to be less than a 50% of a data period error including
>> the variation within a sample clock.
>>
>> To try to gather the data without resynchronizing VASTLY decreases your
>> tolerance for clock errors as you need to stay within a clock cycle over
>> the entire message.
>>
>> The protocol, with its 3 one preamble, does seem like there may have
>> been some effort to enable the use of a PLL to generate the data
>> sampling clock, which may have been the original method. This does have
>> the advantage the the data clock out of the sampler is more regular (not
>> having the sudden jumps from the resyncronizing), and getting a set a
>> burst of 1s helps the PLL to get a bit more centered on the data. My
>> experience though is that with FPGAs (as would be on topic for this
>> group), this sort of PLL synchronism is not normally used, but
>> oversampling clocks with phase correction is fairly standard.
>>
>
> Some form of clock recovery is essential for continuous ('synchronous')
> data streams. It is not required for 'sufficiently short' asynchronous data
> bursts, the classic example of which is RS-232. What I am suggesting is
> that the OP determines - using simulation - whether these frames are too
> long given the relative clock tolerances for a system design without clock
> recovery.
>
> As I previously noted, this is first a 'system design' problem. Only after
> that has been completed does it become an 'FPGA design' problem.
I don't think the frame length is the key parameter, rather it is the 6
zero, one insertion that guarantees a transition every 7 bits.
--
Rick
Article: 155680On 02/08/2013 16:16, rickman wrote: [] >> It is an All Digital PLL: >> >> http://www.aicdesign.org/2003%20PLL%20Slides/L050-ADPLLs-2UP(9_1_03).pdf >> >> all the elements of a PLL are implemented in the digital domain. > > I guess I wasn't aware that a digital PLL wasn't *all* digital. That is > what I have been referring to as digital. you might find this article interesting: http://www.silabs.com/Support%20Documents/TechnicalDocs/AN575.pdfArticle: 155681
On 8/2/13 6:30 AM, alb wrote: > Hi Richard, > > On 02/08/2013 06:22, Richard Damon wrote: > [] >>> The bit-stuffing in long sequences of zeroes is almost certainly there to >>> facilitate a conventional clock recovery method, which I am proposing not >>> using PROVIDED THAT the clocks at each end are within a sufficiently tight >>> tolerance. Detect the ones in the as-sent stream first, then decide which >>> are due to bit-stuffing, and remove them. >>> >>> Deciding how tight a tolerance is 'sufficiently tight' is probably >>> non-trivial, so I won't be doing it for free. >>> >>> >> >> Since a 4x clock allows for a 25% data period correction, and we will >> get an opportunity to do so every 7 data periods, we can tolerate about >> a 25/7 ~ 3% error in clock frequency. (To get a more exact value we will >> need to know details like jitter and sampling apertures, but this gives >> us a good ball-park figure). Higher sampling rates can about double >> this, the key is we need to be able to know which direction the error is >> in, so we need to be less than a 50% of a data period error including >> the variation within a sample clock. > > According to your math it looks like a 2x clock allows for a 50% data > period correction and therefore a 50/7 ~6% error in clock frequency, > which seems to me quite counter intuitive... Am I missing something? > The details are that for a Nx sampling clocks, every time you see a clock, you can possibly shift N/2-1 high speed clock cycles every adjustment. For example, with a 16x clock, you can correct for the edge being between -7 and +7 sampling clocks from the expected point. If it is 8 clocks off, you don't know if is should be +8 or -8, so you are in trouble. If N is odd, you can possibly handle (N-1)/2 cycles. (Note that this assumes negligible jitter.) So our final allowable shift in data clocks is (N/2-1)/N which can also be written as 1/2-1/N, which leads to my 6% for N large (50% correction) and 3% for N=4. For N-2 this gives us 0%. > [] >> The protocol, with its 3 one preamble, does seem like there may have >> been some effort to enable the use of a PLL to generate the data >> sampling clock, which may have been the original method. This does have >> the advantage the the data clock out of the sampler is more regular (not >> having the sudden jumps from the resyncronizing), and getting a set a >> burst of 1s helps the PLL to get a bit more centered on the data. My >> experience though is that with FPGAs (as would be on topic for this >> group), this sort of PLL synchronism is not normally used, but >> oversampling clocks with phase correction is fairly standard. > > This is indeed what I'm looking for, oversampling (4x or 8x) and phase > correct. >Article: 155682
On 8/1/2013 3:21 AM, Svenn Are Bjerkem wrote: > kl. 00:54:41 UTC+2 wednesday 31. july 2013 rickman wrote: >> In fact, I'm skipping Altera for the moment and skipping over to >> MicroSemi and Cypress to see if their combination CPU/Logic devices >> might do the job well and let me eliminate the stereo CODEC to (another >> part that could go obsolete at any time). I seem to recall that the >> Cypress part might be just the ticket but the MicroSemi part runs some >> $50 at the low point. The current Lattice part is running under $10. > > We've got a quote for the Microsemi SF2 M2S010 (without T) somewhere in the middle of that price difference in low volume. The features of SF2 somehow justified the additional price because we could avoid a separate flash and MCU externally. The flexibility in configuration of the FPGA and MSS and hard preipherals also give us design freedom. Low power consumption was definitively something worth a bit extra. I had a chance to look at the Smart Fusion 2 devices, and they seem to be too much device for this project. The M2S005 would likely be a good fit with a lot more logic than needed, but the smallest package it comes in is a fine pitch BGA with 400 pins! I guess they are targeting much larger apps than mine. I still need to take a better look at the Cypress parts if I can figure out how to get a data sheet. -- RickArticle: 155683
Rick, It seems to me that you have changed your goals around a bit and it is not = clear to me exactly what you are looking for anymore but from what I can ga= ther I still think you are missing out on a decent choice if you are ignori= ng the actel/microsemi igloo parts. Take another look at the agl250 line. = If you need the smaller quad flat pack it is there, I would imagine there = is plenty of logic for your existing product and it is inexpensive. They h= ave a chip in the same package with a cortex m1 if you want an embedded uC = too. I personally prefer to design with Xilinx first then altera then actel but = will definitely go with actel when the design needs it, they just tend to r= un a bit slower than what I like. I have looked at using the cypress chips= before for the USB capability back around 2005 but was not able to get the= windows side working right with the jungo driver so went with the USB to u= art parts from ftdi instead. Never looked back to cypress or jungo since t= hen.Article: 155684
On 8/4/2013 4:09 PM, Chris wrote: > Rick, > > It seems to me that you have changed your goals around a bit and it is not clear to me exactly what you are looking for anymore but from what I can gather I still think you are missing out on a decent choice if you are ignoring the actel/microsemi igloo parts. Take another look at the agl250 line. If you need the smaller quad flat pack it is there, I would imagine there is plenty of logic for your existing product and it is inexpensive. They have a chip in the same package with a cortex m1 if you want an embedded uC too. The goal is to live a rich, full life... ;) There are any number of ways to do that. I have gone through all the major FPGA makers, including MicroSemi and created a spread sheet of the devices which might substitute for the Lattice part that has been discontinued. I may have given the Igloo parts short shrift because I seem to recall they use Versa tiles for both logic an FFs, so you need twice as many if you need both FFs and 4 input LUTs. The Lattice FPGA being replaced has some 3000 LUTs and 3000 FFs, IIRC so the AGLN250 might suit the requirement. It would be nicer if the new device offered some new capability such as more logic and/or multipliers. So I should at least include this part in my selection even if it does not provide any new capabilities. > I personally prefer to design with Xilinx first then altera then actel but will definitely go with actel when the design needs it, they just tend to run a bit slower than what I like. I have looked at using the cypress chips before for the USB capability back around 2005 but was not able to get the windows side working right with the jungo driver so went with the USB to uart parts from ftdi instead. Never looked back to cypress or jungo since then. As to my seeming switching of requirements, we *have* to replace the FPGA. There is also a CODEC from AKM on the board which could be hard to replace should it also go obsolete. It is just as old as the FPGA and I have no insight about when AKM might obsolete it. Everything else on the board is second sourced. So if we are building a new model, I want to have a plan for providing some assurance the CODEC won't cause another redesign in a couple of years. One way of doing this is to combine the CODEC function with the FPGA (hence looking at the Microsemi MCU/FPGA device which turns out to be rather pricey) or possibly use an MCU (with adequate analog I/O) and a smaller FPGA. Only a portion of the current FPGA design has to be in an FPGA, most of it is slow logic can be turned into software. SiLabs seems to make an 8051 type chip with 16 bit ADCs and fast 12 bit DACs. I might be able to dither the DACs to provide higher resolution on the output. I need to also look at Cirrus Logic. I seem to recall they make some parts that might work. Its hard because of the limited board space, but two smaller devices might actually take up less board space than one large one. Providing a 5 volt tolerant interface would also eliminate some other chips and free up more board space. Both ADI and TI have DSP/CODEC devices, but they aren't designed for general purpose programming and just don't suit the need. -- RickArticle: 155685
Well I am jealous that sounds like a fun project. One other thing that cam= e to mind as this was going through my head today was the fpslic from atmel= , we looked at using one a while back but ultimately decided on splitting t= he design into a cpld (coolrunner) and an atmega128. Best of luck and let me know what you decide on, it is interesting to me.Article: 155686
On 8/5/2013 12:42 AM, Chris wrote: > Well I am jealous that sounds like a fun project. One other thing that came to mind as this was going through my head today was the fpslic from atmel, we looked at using one a while back but ultimately decided on splitting the design into a cpld (coolrunner) and an atmega128. > > Best of luck and let me know what you decide on, it is interesting to me. Wow! I had no idea they still made the FPSLIC. That is *very* long in the tooth and I believe it never had much market penetration so that I expect many potential users were put off thinking it would be scrapped. Actually, if we had any assurance that would be made for the next 5-10 years, it likely could be a perfect fit. IIRC it had an AVR CPU and some amount of the LUT based Atmel FPGA fabric. That would do a great job of offloading the FPGA fabric with the AVR and likely is 5 volt compatible so potentially saving some chips. But I'm pretty sure this is not well supported and likely to be dumped any time. It's what, at least 10 years old, maybe 15. Heck, if the sky were the limit, I think this design could be done in the GA144, a multiprocessor chip which I think is more like an FPGA with processors in place of LUTs (I call it a FPPA, Field Programmable Processor Array). But the company making them is very small and I doubt they will be around in five years. As to the "fun" aspect, yes, it is a bit of fun, but this is not a salaried job, this is my *business*, so the seriousness takes away a lot of the "fun". I need to impress the customer that I can give them a new design that will last for at least 5 years and I would like to provide them potential for new applications. -- RickArticle: 155687
On 7/31/2013 7:48 PM, Chris wrote: > Rick... I check the Actel/Microsemi lead you started down on the original post, they have options available in your target size, 100 pin QFP, are flash based/reprogrammable over JTAG and I think should have very similar power requirements to your original design. I am looking at this chip, available today on digikey: AGL250V2-VQG100, 14 mm2, $25.40, 68 I/O and a fair amount of logic. If you don't need that much logic and want a cheaper part they go down from there in the same package. Ok, I finally figured it out. Sometimes I am a little slow. The AGL parts are just Igloo which is combined on a web page with the IGLOOe parts. The link said IGLOO/e which made me think it was just the e parts with the ARM M1 core enabled and I kept skipping that one. Still, I find the parts to be a bit confusing. I'm not certain what the difference between the IGLOO and the IGLOOnano is. It appears the nano is slightly lower power, but I don't see just how much lower. The IGLOO parts seem to come in an M1 version even without the 'e'. In fact the lowest cost part in the AGL250 flavor (RoHS) is the M1 version! Not sure just what that even means. I think my main concern is that these parts are long in the tooth, but I'll add them to my spread sheet since they are the only ones that can fit the board without adding parts or going to a much tougher footprint to use. -- RickArticle: 155688
>On 8/2/2013 6:35 AM, RCIngham wrote:
>>> On 8/1/13 5:56 AM, RCIngham wrote:
>>>>> On 7/31/13 9:36 AM, RCIngham wrote:
>>>>>> [snip]
>>>>>>>
>>>>>> Unless 'length' is limited, your worst case has header
>>>> "0000001111111111"
>>>>>> (with an extra bit stuffed) followed by 16 * 1023 = 16368 zeros,
>> which
>>>> will
>>>>>> have 2728 ones stuffed into them. Total line packet length is 19113
>>>>>> symbols. If the clocks are within 1/19114 of each other, the same
>> number
>>>> of
>>>>>> symbols will be received as sent, ASSUMING no jitter. You can't
>> assume
>>>>>> that, but if there is 'not much' jitter then perhaps 1/100k will be
>>>> good
>>>>>> enough for relative drift to not need to be corrected for.
>>>>>>
>>>>>> So, for version 1, use the 'sync' to establish the start of frame
and
>>>> the
>>>>>> sampling point, simulate the 'Rx fast' and 'Rx slow' cases in
>> parallel,
>>>> and
>>>>>> see whether it works.
>>>>>>
>>>>>> BTW, this is off-topic for C.A.F., as it is a system design problem
>> not
>>>>>> related to the implementation method.
>>>>>>
>>>>>>
>>>>>
>>>>> Since you can resynchronize your sampling clock on each transition
>>>>> received, you only need to "hold lock" for the maximum time between
>>>>> transitions, which is 7 bit times. This would mean that if you have
a
>>>>> nominal 4x clock, some sample points will be only 3 clocks apart (if
>> you
>>>>> are slow) or some will be 5 clocks apart (if you are fast), while
most
>>>>> will be 4 clock apart. This is the reason for the 1 bit stuffing.
>>>>>
>>>>
>>>> The bit-stuffing in long sequences of zeroes is almost certainly
there
>> to
>>>> facilitate a conventional clock recovery method, which I am proposing
>> not
>>>> using PROVIDED THAT the clocks at each end are within a sufficiently
>> tight
>>>> tolerance. Detect the ones in the as-sent stream first, then decide
>> which
>>>> are due to bit-stuffing, and remove them.
>>>>
>>>> Deciding how tight a tolerance is 'sufficiently tight' is probably
>>>> non-trivial, so I won't be doing it for free.
>>>>
>>>>
>>>
>>> Since a 4x clock allows for a 25% data period correction, and we will
>>> get an opportunity to do so every 7 data periods, we can tolerate
about
>>> a 25/7 ~ 3% error in clock frequency. (To get a more exact value we
will
>>> need to know details like jitter and sampling apertures, but this
gives
>>> us a good ball-park figure). Higher sampling rates can about double
>>> this, the key is we need to be able to know which direction the error
is
>>> in, so we need to be less than a 50% of a data period error including
>>> the variation within a sample clock.
>>>
>>> To try to gather the data without resynchronizing VASTLY decreases
your
>>> tolerance for clock errors as you need to stay within a clock cycle
over
>>> the entire message.
>>>
>>> The protocol, with its 3 one preamble, does seem like there may have
>>> been some effort to enable the use of a PLL to generate the data
>>> sampling clock, which may have been the original method. This does
have
>>> the advantage the the data clock out of the sampler is more regular
(not
>>> having the sudden jumps from the resyncronizing), and getting a set a
>>> burst of 1s helps the PLL to get a bit more centered on the data. My
>>> experience though is that with FPGAs (as would be on topic for this
>>> group), this sort of PLL synchronism is not normally used, but
>>> oversampling clocks with phase correction is fairly standard.
>>>
>>
>> Some form of clock recovery is essential for continuous ('synchronous')
>> data streams. It is not required for 'sufficiently short' asynchronous
data
>> bursts, the classic example of which is RS-232. What I am suggesting is
>> that the OP determines - using simulation - whether these frames are
too
>> long given the relative clock tolerances for a system design without
clock
>> recovery.
>>
>> As I previously noted, this is first a 'system design' problem. Only
after
>> that has been completed does it become an 'FPGA design' problem.
>
>I don't think the frame length is the key parameter, rather it is the 6
>zero, one insertion that guarantees a transition every 7 bits.
>
>--
>
>Rick
>
Simulation or other experiment will indicate which of us (if either) is
correct.
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 155689Xilinx Xapp224 , which describes data recovery using 4x oversampling, might be useful to the OP.Article: 155690
Or by adjusting placement to create appropriate skew in the clock arrival times at the source and destination registers. I'm not sure why they allow the option to be disabled... AndyArticle: 155691
On Friday, August 2, 2013 9:41:30 AM UTC-4, Theo Markettos wrote: > Anssi Saari <as@sci.fi> wrote: > Vivek Menon <vivek.menon79@gmail.com> wr= ites: > > > I have my SOPC_KIT_NIOS2 path set to C:\altera\80\nios2eds > > = > > Any suggestions?? > > Clearly make isn't found. Look for make.exe under= C:\altera and check > what directories you have in your PATH. make was fou= nd, but it couldn't run /bin/sh.exe (I think it's using cygwin). Check your= PATH, and otherwise I'd reinstall the tools as something is obviously wron= g in the cygwin install it's using. You don't have cygwin elsewhere on the = machine do you? Are you running these from the GUI or from the shell? Theo @Theo: I don't have any other cygwin installations. I am running the GUI. I haven't found make.exe in altera folder. any suggestions on where to find= it in altera quartus v8.0 ?Article: 155692
On Friday, August 2, 2013 9:41:30 AM UTC-4, Theo Markettos wrote: > Anssi Saari wrote: > Vivek Menon writes: > > > I have my SOPC_KIT_NIOS2 p= ath set to C:\altera\80\nios2eds > > > > Any suggestions?? > > Clearly make= isn't found. Look for make.exe under C:\altera and check > what directorie= s you have in your PATH. make was found, but it couldn't run /bin/sh.exe (I= think it's using cygwin). Check your PATH, and otherwise I'd reinstall the= tools as something is obviously wrong in the cygwin install it's using. Yo= u don't have cygwin elsewhere on the machine do you? Are you running these = from the GUI or from the shell? Theo @Theo:=20 I don't have any other cygwin installations. I am running the GUI.=20 I haven't found make.exe in altera folder. any suggestions on where to find= it in altera quartus v8.0 ?=20Article: 155693
Vivek Menon <vivek.menon79@gmail.com> wrote: > I don't have any other cygwin installations. I am running the GUI. > I haven't found make.exe in altera folder. any suggestions on where to > find it in altera quartus v8.0 ? I'm afraid I have no idea, because I don't use Quartus on Windows and v8.0 is now 5 years old. However the error message appears to be in make format, in other words there's a Make executable somewhere on your system and it's executing fine. What isn't working is invoking new processes from Make, probably because it can't invoke a shell. That could be an actual sh.exe (most likely) or some Cygwin magic. My guess would be one of the NIOS2_* environment variables isn't right, but couldn't say which it might be. TheoArticle: 155694
Hey folks, my team just published a new issue of Xcell Journal. The issue h= as a cover story on UltraScale, which should shed a bit more light on the p= roduct strategy (at least what we are revealing so far). The issue also has= some great how to and methodology pieces. Here is a link to Xcell's landin= g page where you can download a pdf of the entire issue or read in the digi= tal magazine format (which is iPad/iPhone compatible). http://www.xilinx.co= m/publications/xcellonline/index.htm If you ever want to contribute a piece to Xcell, just send me an email. Mik= e.santarini at Xilinx dot com. Cheers, Mike SantariniArticle: 155695
Hi everyone, I'm trying to understand the details of each individual step from my source code to a running a postlayout simulation with ModelSim. I've read several articles on what are the steps, I've also checked the default run.do script which ModelSim uses to do everything, but on top of *what* I need to do I'd appreciate to understand *why* I need to do so and *which* are the control files I need to know. The workflow I'm interested in is the following: 1. editing vhdl code 2. compilation 3. presynthesis simulation 4. synthesis 5. postsynthensis simulation 6. place&route 7. postlayout simulation Step 1. is fairly easy, a text editor and I'm done (better be emacs!). In order to perform 2. I need to use 'vcom' from ModelSim, but before doing that I need to specify which is my library. In order to do that, in the default run.do the following commands are executed: $ vlib presynth $ vmap presynth presynt $ vmap igloo /path/to/igloo/library/from/actel Now. While I understand the need to 'create' a library (BTW, what happened to 'work'!) I was puzzled on the need to map the library, but then I figured that when running vmap a modelsim.ini file is created for ModelSim to look at at startup in order to know where to look for libraries. To be more precise it would be 'vcom' that needs that piece of information, correct? If this is the case, when I need to run 5. I will need to grab the vhd generated by the synthesis (why do I need a vhd and not the edf/edn file?), create a postsynth library, map it and then compile in there the file with all the necessary files for the testbench. Is that correct? If this is correct, when moving on to 7. it seems that I need to get the backannotated vhdl from the p&r tool, create a postlayout library, map it and compile the vhdl in it with the associated testbench. If I'm on track with this, then I'd like to continue with simulating in batch mode (I'm mainly interested in regression tests automatically started). Here's is one hit I've found on running vsim in batch mode: https://ece.uwaterloo.ca/~ece327/protected/modelsim/htmldocs/mgchelp.htm#context=modelsim_se_user&id=16&tab=0&topic=NoNespecified What is strange is the use of a test.do script which may severely affect everything since I can ran whatever command in a do script... I'm not sure how much I want to depend on that. The default run.do instead has the following part: [skip compilation section] > vsim -L igloo -L presynth -t 1ps presynth.testbench > add wave /testbench/* > run 1000ns > log testbench/* > exit where I presume testbench is my top level testbench entity (what about the architecture!?!). And I also presume that this run.do is called from the ModelSim terminal, therefore I need to understand a little bit how can I pass it through command line (-c option??). It seems to me that these instructions could also be passed to vsim in batch mode and have it logging waveforms in external files (http://research.cs.berkeley.edu/class/cs/61c/modelsim/). For regression testing maybe waveforms are not so much interesting and a report is more useful, maybe with a coverage report as well, but before hitting that phase I believe I'll be looking a lot at waves and I better be prepared for being able to have them somewhere. After all this rant I think I bored you already to death, but believe me that while writing this article I checked and verified all my stupid thoughts, ending up with knowing much more than what I did yesterday night when I started writing... I guess I will continue to post my reasoning as I proceed with this quest, hoping not to annoy anyone :-). And of course if anybody notices I'm falling off track please give me a shout! Al -- A: Because it fouls 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: 155696
[snipped]
ModelSim looks in either 'modelsim.ini' or (if you are using it)
'your_project.mpf' quite often, including for library mappings. Open these
files with a text editor (when ModelSim not running) and study them.
In your script which performs compilation you may want to include code to
delete-and-reinitialise libraries to ensure that you are using only the
latest code, for instance something like:
if { [file exists test] } {
vdel -lib test -all
}
vlib -long test
vmap test test
Different code may be required if using ModelSim 10.2 or later.
For post-synthesis simulations and post-layout simulations you will need to
reference the libraries with the technology-specific primitives.
I recommend that you Read The Fine Manuals, both the User Guide and the
Reference Manual.
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 155697
Hi Robert,
On 08/08/2013 15:48, RCIngham wrote:
> [snipped]
>
> ModelSim looks in either 'modelsim.ini' or (if you are using it)
> 'your_project.mpf' quite often, including for library mappings. Open these
> files with a text editor (when ModelSim not running) and study them.
apparently mpf is not used. My modelsim.ini looks like this (my comments
included):
> [Library]
so here it begins a list of libraries...
> others = $MODEL_TECH/../modelsim.ini
this one is a library, but looks like another ini file. Does it work as
include?
> igloo = /opt/microsemi/Libero_v10.1/Libero/lib/modelsim/precompiled/vhdl/igloo
this is mapped with vmap igloo /bla/bla/bla
> syncad_vhdl_lib = /opt/microsemi/Libero_v10.1/Libero/lib/actel/syncad_vhdl_lib
this one here apparently is not found and I believe is not used anywhere.
> presynth = presynth
> postsynth = postsynth
> postlayout = ../designer/impl1/simulation/postlayout
as igloo above, these libraries are mapped from the path they belong to.
> [vcom]
now it begins a section related to the compiler
> VHDL93 = 93
>
> NoDebug = 0
> Explicit = 0
> CheckSynthesis = 0
> NoVitalCheck = 0
> Optimize_1164 = 1
> NoVital = 0
> Quiet = 0
> Show_source = 0
> DisableOpt = 0
> ZeroIn = 0
> CoverageNoSub = 0
> NoCoverage = 0
> Coverage = sbcef
> CoverCells = 1
> CoverExcludeDefault = 0
> CoverFEC = 1
> CoverShortCircuit = 1
> CoverOpt = 3
> Show_Warning1 = 1
> Show_Warning2 = 1
> Show_Warning3 = 1
> Show_Warning4 = 1
> Show_Warning5 = 1
These details I ignore for the time being, I believe they can be easily
understood with the User Manual.
> [vsim]
while here's a section related to the simulator
> IterationLimit = 5000
> VoptFlow = 1
> [vlog]
[]
I do not use verilog, therefore I can safely skip this part as of now...
> In your script which performs compilation you may want to include code to
> delete-and-reinitialise libraries to ensure that you are using only the
> latest code, for instance something like:
>
> if { [file exists test] } {
> vdel -lib test -all
> }
> vlib -long test
> vmap test test
Uhm, I thought that bringing the project up-to-date was done by make,
simply checking at the files' timestamps. I understand that make cannot
guarantee that vcom does not write properly the 'object' in the library,
therefore your suggestion might be on the safe side. The only issue with
this approach is that I would need to recompile every time the whole
library.
In my run.do instead there's somewhat the contrary:
> if {[file exists presynth/_info]} {
> echo "INFO: Simulation library presynth already exists"
> } else {
> vlib presynth
> }
no need to recreate the whole project. If I remove the library I will
need than to recompile based on the missing 'object'. vmk creates
Makefile rules which are relative to empty files with the name of the
file being compiled. Every time the source is modified it will be also
recompiled and added to the library. This is fairly simple because it
allows me to do rules without the need to know what type of objects vcom
is generating.
OTOT I lately realized that if you organize the sources to have entities
and architectures (or packages definitions and bodies) on separate files
then you can drastically reduce the amount of dependencies and therefore
recompilation.
Article: 155698Am Donnerstag, 8. August 2013 15:19:27 UTC+2 schrieb alb: > Hi everyone, > > > > I'm trying to understand the details of each individual step from my > > source code to a running a postlayout simulation with ModelSim. I've > > read several articles on what are the steps, I've also checked the > > default run.do script which ModelSim uses to do everything, but on top > > of *what* I need to do I'd appreciate to understand *why* I need to do > > so and *which* are the control files I need to know. > > > > The workflow I'm interested in is the following: > > > > 1. editing vhdl code > > 2. compilation > > 3. presynthesis simulation > > 4. synthesis > > 5. postsynthensis simulation > > 6. place&route > > 7. postlayout simulation > > > > Step 1. is fairly easy, a text editor and I'm done (better be emacs!). > > In order to perform 2. I need to use 'vcom' from ModelSim, but before > > doing that I need to specify which is my library. In order to do that, > > in the default run.do the following commands are executed: > > > > $ vlib presynth > > $ vmap presynth presynt > > $ vmap igloo /path/to/igloo/library/from/actel > > > > Now. While I understand the need to 'create' a library (BTW, what > > happened to 'work'!) I was puzzled on the need to map the library, but > > then I figured that when running vmap a modelsim.ini file is created for > > ModelSim to look at at startup in order to know where to look for > > libraries. To be more precise it would be 'vcom' that needs that piece > > of information, correct? > > > > If this is the case, when I need to run 5. I will need to grab the vhd > > generated by the synthesis (why do I need a vhd and not the edf/edn > > file?), create a postsynth library, map it and then compile in there the > > file with all the necessary files for the testbench. Is that correct? > > > > If this is correct, when moving on to 7. it seems that I need to get the > > backannotated vhdl from the p&r tool, create a postlayout library, map > > it and compile the vhdl in it with the associated testbench. > > > > If I'm on track with this, then I'd like to continue with simulating in > > batch mode (I'm mainly interested in regression tests automatically > > started). Here's is one hit I've found on running vsim in batch mode: > > > > https://ece.uwaterloo.ca/~ece327/protected/modelsim/htmldocs/mgchelp.htm#context=modelsim_se_user&id=16&tab=0&topic=NoNespecified > > > > What is strange is the use of a test.do script which may severely affect > > everything since I can ran whatever command in a do script... I'm not > > sure how much I want to depend on that. The default run.do instead has > > the following part: > > > > [skip compilation section] > > > vsim -L igloo -L presynth -t 1ps presynth.testbench > > > add wave /testbench/* > > > run 1000ns > > > log testbench/* > > > exit > > > > where I presume testbench is my top level testbench entity (what about > > the architecture!?!). And I also presume that this run.do is called from > > the ModelSim terminal, therefore I need to understand a little bit how > > can I pass it through command line (-c option??). > > > > It seems to me that these instructions could also be passed to vsim in > > batch mode and have it logging waveforms in external files > > (http://research.cs.berkeley.edu/class/cs/61c/modelsim/). For regression > > testing maybe waveforms are not so much interesting and a report is more > > useful, maybe with a coverage report as well, but before hitting that > > phase I believe I'll be looking a lot at waves and I better be prepared > > for being able to have them somewhere. > > > > After all this rant I think I bored you already to death, but believe me > > that while writing this article I checked and verified all my stupid > > thoughts, ending up with knowing much more than what I did yesterday > > night when I started writing... > > > > I guess I will continue to post my reasoning as I proceed with this > > quest, hoping not to annoy anyone :-). And of course if anybody notices > > I'm falling off track please give me a shout! > > > > Al > > > > -- > > A: Because it fouls 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? Hi Al, you seem to make things much more complicated than they are. Some simple hints: To start modelsim from th ecommandline: vsim -do myscript.do The -L option in vsim is for verilog simulations only, isn't it? You might let it away, unless you don't do mixed mode simulations. If you don't explicitly mention an architecture in a vsim command, the first one is taken from the library. Testbenches mostly have just one architecture anyway. Design models often have multiple architectures for different implementation styles or other purposes (behavioral, structural_post_par etc.). When you create a local library, no vmap is needed. vlib my_library is sufficient. Also this can be done just once, because as you already have seen it is stored in the ini file. If you are using libraries more often, like the vendor libraries, you should put them in a higher level ini file, so they are present for all your projects. (Ini files are read in beginning from the modelsim install path, then the users home dir and finally the project dir. The first one is global but can be partly overwritten by the later ones) The work library is normally local, so at the creation of a project you need to do a vlib work just once. Then you have a default saving you from always mentioning some self created local library name. By the way, behavioral simulation (presyn) and timing simulation (post-par) make sense. What's the benefit of a post-syn simulation? Is it just to distinguish synthesis tool bugs from design bugs? Have a nice simulation EilertArticle: 155699
>Hi Robert,
>
>On 08/08/2013 15:48, RCIngham wrote:
>> [snipped]
>>
>> ModelSim looks in either 'modelsim.ini' or (if you are using it)
>> 'your_project.mpf' quite often, including for library mappings. Open
these
>> files with a text editor (when ModelSim not running) and study them.
>
>apparently mpf is not used. My modelsim.ini looks like this (my comments
>included):
>
>> [Library]
>so here it begins a list of libraries...
>> others = $MODEL_TECH/../modelsim.ini
>
>this one is a library, but looks like another ini file. Does it work as
>include?
Yes, as described in their fine documentation.
[snip]
>> In your script which performs compilation you may want to include code
to
>> delete-and-reinitialise libraries to ensure that you are using only the
>> latest code, for instance something like:
>>
>> if { [file exists test] } {
>> vdel -lib test -all
>> }
>> vlib -long test
>> vmap test test
>
>Uhm, I thought that bringing the project up-to-date was done by make,
>simply checking at the files' timestamps. I understand that make cannot
>guarantee that vcom does not write properly the 'object' in the library,
>therefore your suggestion might be on the safe side. The only issue with
>this approach is that I would need to recompile every time the whole
>library.
If you want to use 'make' (or 'vmake') I cannot assist further. We don't
use it here. Formal synthesis builds are ALWAYS done from scratch, and I
suspect that formal verification is similar.
[snip]
---------------------------------------
Posted through http://www.FPGARelated.com
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