Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 155675

Article: 155675
Subject: Re: serial protocol specs and verification
From: "RCIngham" <2161@embeddedrelated>
Date: Fri, 02 Aug 2013 05:35:58 -0500
Links: << >>  << T >>  << A >>
>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: 155676
Subject: Re: NiosII 8.0 make error Windows XP
From: Anssi Saari <as@sci.fi>
Date: Fri, 02 Aug 2013 13:41:21 +0300
Links: << >>  << T >>  << A >>
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.

Article: 155677
Subject: Re: NiosII 8.0 make error Windows XP
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 02 Aug 2013 14:41:30 +0100 (BST)
Links: << >>  << T >>  << A >>
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?

Theo

Article: 155678
Subject: Re: serial protocol specs and verification
From: rickman <gnuarm@gmail.com>
Date: Fri, 02 Aug 2013 10:16:04 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 155679
Subject: Re: serial protocol specs and verification
From: rickman <gnuarm@gmail.com>
Date: Fri, 02 Aug 2013 10:20:47 -0400
Links: << >>  << T >>  << A >>
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: 155680
Subject: Re: serial protocol specs and verification
From: alb <alessandro.basili@cern.ch>
Date: Fri, 02 Aug 2013 17:05:44 +0200
Links: << >>  << T >>  << A >>
On 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.pdf



Article: 155681
Subject: Re: serial protocol specs and verification
From: Richard Damon <Richard@Damon-Family.org>
Date: Fri, 02 Aug 2013 19:40:48 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: rickman <gnuarm@gmail.com>
Date: Sat, 03 Aug 2013 02:11:17 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 155683
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: Chris <catalsma@gmail.com>
Date: Sun, 4 Aug 2013 13:09:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: rickman <gnuarm@gmail.com>
Date: Mon, 05 Aug 2013 00:05:56 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 155685
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: Chris <catalsma@gmail.com>
Date: Sun, 4 Aug 2013 21:42:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: rickman <gnuarm@gmail.com>
Date: Mon, 05 Aug 2013 01:00:10 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 155687
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: rickman <gnuarm@gmail.com>
Date: Mon, 05 Aug 2013 01:54:25 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 155688
Subject: Re: serial protocol specs and verification
From: "RCIngham" <2161@embeddedrelated>
Date: Mon, 05 Aug 2013 03:53:19 -0500
Links: << >>  << T >>  << A >>
>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: 155689
Subject: Re: serial protocol specs and verification
From: edmoore <edmoore1966@googlemail.com>
Date: Mon, 5 Aug 2013 01:53:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
Xilinx Xapp224 , which describes data recovery using 4x oversampling, might be useful to the OP.

Article: 155690
Subject: Re: seperate high speed rules for HDL?
From: jonesandy@comcast.net
Date: Mon, 5 Aug 2013 05:46:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
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...

Andy

Article: 155691
Subject: Re: NiosII 8.0 make error Windows XP
From: Vivek Menon <vivek.menon79@gmail.com>
Date: Mon, 5 Aug 2013 06:04:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: NiosII 8.0 make error Windows XP
From: Vivek Menon <vivek.menon79@gmail.com>
Date: Mon, 5 Aug 2013 06:05:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 ?=20

Article: 155693
Subject: Re: NiosII 8.0 make error Windows XP
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 06 Aug 2013 01:03:35 +0100 (BST)
Links: << >>  << T >>  << A >>
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.

Theo

Article: 155694
Subject: Xilinx Xcell Journal 84--Xilinx Goes UltraScale
From: mike.santarini@gmail.com
Date: Tue, 6 Aug 2013 10:28:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 Santarini

Article: 155695
Subject: [cross-post] vlib, vmap, vcom, how it all works...
From: alb <alessandro.basili@cern.ch>
Date: Thu, 08 Aug 2013 15:19:27 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: [cross-post] vlib, vmap, vcom, how it all works...
From: "RCIngham" <2161@embeddedrelated>
Date: Thu, 08 Aug 2013 08:48:14 -0500
Links: << >>  << T >>  << A >>
[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
Subject: Re: [cross-post] vlib, vmap, vcom, how it all works...
From: alb <alessandro.basili@cern.ch>
Date: Thu, 08 Aug 2013 18:07:57 +0200
Links: << >>  << T >>  << A >>
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: 155698
Subject: Re: [cross-post] vlib, vmap, vcom, how it all works...
From: goouse99@gmail.com
Date: Fri, 9 Aug 2013 00:04:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
Am 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
  Eilert

Article: 155699
Subject: Re: [cross-post] vlib, vmap, vcom, how it all works...
From: "RCIngham" <2161@embeddedrelated>
Date: Fri, 09 Aug 2013 04:38:30 -0500
Links: << >>  << T >>  << A >>
>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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search