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 154300

Article: 154300
Subject: Re: Getting in to the industry
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Mon, 24 Sep 2012 09:32:40 -0700
Links: << >>  << T >>  << A >>
On Sun, 23 Sep 2012 13:03:27 -0500
"James823" <3681@embeddedrelated> wrote:

> Hi,
> I'm new to FPGAs but would like to get into the industry. Aside from
> building and playing around with toy projects, what can I do to help put me
> ahead of the other EE graduates?
> What kind of projects could be attempted with a starter kit that would put
> hairs on my chest so to speak?
> 
> Thanks
> James
> 
> 	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

The toy projects have value as well.  The tools all have enough
"personality" to them that simply having bulled your way through them
in order to make anything work is a non-trivial achievement.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 154301
Subject: Re: multi-source errors
From: Gabor <gabor@szakacs.invalid>
Date: Mon, 24 Sep 2012 16:05:16 -0400
Links: << >>  << T >>  << A >>
smileforthecamerahotshot@gmail.com wrote:
> On Sunday, September 23, 2012 5:58:45 PM UTC-7, Gabor wrote:
>>> Any help is appreciated. I get errors of the following sort:
>>> "Multi-source in Unit <tst_1> on signal <ram<15><3>>; this signal is connected to multiple drivers."
>>> The source for the entire unit in question is as follows:
[code snipped]
>>> For the interested, I get multi-source errors on ram[15][3], ram[15][2], and ram[15][0]... but not ram[15][1]. Since the signals in question are all driven from different states within the same FSM, I am not sure why this is considered multiple drivers. I am sure this is something obvious to the well-informed. Any ideas?
>> Perhaps ram[15][1] is never driven to a value other than zero and has
>> been "replaced by logic."  What tools are you using, and what version?
>> I have seen a lot of bogus multi-source messages from Xilinx XST
>> especially when using arrays and loops.  Theoretically any number
>> of assignments in the same process should never create a multi-source
>> error.
>>
>> -- Gabor
> I am using Xilinx ISE WebPACK v12.4 (nt64). I also tried this using ISE WebPACK 9.2i 32-bit and get the same errors. I have tried targeting an XC3S500E and an XC3S1600E. One thing that I noticed is that if I change the s_0 state to do this "ram[15][7:0] <= 8'h00;" instead of this "ram[15] <= 8'h00;" then I get no errors. I don't understand this.

It looks like a bug, so you might want to try to use the "new"
parser in ISE 12.4 (or later) by adding the following to the
"other command line options" in the XST synthesis properties:

-use_new_parser yes

-- Gabor

Article: 154302
Subject: Just gloating
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Mon, 24 Sep 2012 17:32:33 -0700
Links: << >>  << T >>  << A >>
I've got a VHDL design in which I use record types as a convenient way
of wiring up my internal buses.  This design is a single-master,
multiple slave bus.  The default assignment to all of the slaves puts
don't cares ('X', actually) on the data and address lines for any slave
not currently in use, it's only the control signals that get specific
assignments that tell the slave it's not in use.

You'd think that, in this case, the optimized logic for the slave
data and address buses would simply be a wire.  Today I built the design
under Quartus 12.0. And that was exactly what happened.  My don't cares
were actually handled in a logical manner that reduced the amount of
logic used.

The last time I tried this, under ISE 12.3, this was not the case, and
I wasted a huge amount of effort getting the excess logic out of my
data and address paths so as to keep from using up unnecessary
resources and complicating my timing.  Today, what should have just
worked just worked.

It's a good day.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 154303
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: Jon Elson <elson@pico-systems.com>
Date: Mon, 24 Sep 2012 22:06:43 -0500
Links: << >>  << T >>  << A >>
nba83 wrote:

> hi
> i would like to drive a Digital to analog converter(AD1933) with a cpld,
> here is what i'm trying to do: i have a micro controller that generate
> 25Mbps DAC data but is not capable of driving the DAC through high speed
> SPI(i need over 35MHz spi interface), so i decided to drive the dac with
> cpld or fpga,
> since i don't want to increase project cost by using fpga so i prefer to
> use cpld XC95XX(XC95144) for this application, i'm not sure if this cpld
> is capable of driving the dac at this rate, any one have any idea about
> the feasibility of this plan??
The 9500XL series starts out very cheap, but the larger components,
like the 95144, start to get expensive.  You can check the prices of
the CoolRunner series (XCR), also quite cheap even in the larger sizes.
But, you are talking about significant amounts of registers, and
the CPLDs are very short on them.  Block RAMs don't exist at all
on Xilinx CPLDs, and probably not on anybody else's, either.

The smaller Spartan 3A are quite inexpensive, but need a download
serial PROM.  SST's 25VF010A will load the XC3S50A FPGA with no
additional chips, and is under $1 in small quantity.  You can get the
Spartan 3AN version of the FPGA with built-in SPROM, but it costs
more than the separate solution.  You do need to find a way to
program the SST SPROM, but it is fairly easy to do.  Totally minimal
hardware, and pretty simple software.

Jon

Article: 154304
Subject: Multiple IDELAYCTRLs in V-5: how, and why?
From: nospam@nospam.com
Date: Tue, 25 Sep 2012 09:05:43 +0100
Links: << >>  << T >>  << A >>
I'm on Virtex-5, and have a lot of IODELAYs, for fixed and variable
input delays. I've read chapter 7 of the User Guide, and AR #39966,
about IODELAY_GROUPs. I need to instantiate one or more IDELAYCTRLs,
and my options are (1) to instantiatiate one of them, and let the tool
fix everything up, or (2) instantiate lots of them, and do it all by
hand.

Here's the bit I don't understand. What's wrong with (1)? 

Page 342 of ug190 says "The most efficient way to use the IDELAYCTRL
module is to define and lock down the placement of every IDELAYCTRL
instance used in a design....Xilinx strongly recommends using
IDELAYCTRL with a LOC constraint", but the UG doesn't seem to say
anywhere why this is the case. What's the point? And why don't the
tools just conenct up the IDELAYCTRLs anyway, without being told to?
The IODELAY is useless without it.

Thanks. 



Article: 154305
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: "nba83" <3224@embeddedrelated>
Date: Tue, 25 Sep 2012 06:09:13 -0500
Links: << >>  << T >>  << A >>
>On Mon, 24 Sep 2012 06:00:15 -0500
>"nba83" <3224@embeddedrelated> wrote:
>
>> >On 09/24/2012 08:09 AM, nba83 wrote:
>> >
>> >> I want to feed data in parallel (8bit) to CPLD, buffer it for about
100
>> >> bytes, and then start to drive SPI Out. I am some how concerned
about
>> the
>> >> speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it is
>> >> -10C(means 10nsec delay for IO routs), does this delay impose any
>> problem?
>> >> Since I want to drive the CPLD with 100MHZ oscillator clk input, and
by
>> clk
>> >> dividing generate a 50 or 40MHz clk for SPI.
>> >> tnx for any helpful comments :)
>> >
>> >The problem isn't going to be the speed, but where the CPLD is going to

>> >store the 100 bytes. The XC95144XL only has 144 bits of storage total.
>> >
>> >
>> 
>> I have implemented a 1k byte dual port ram in this cpld logic  in
xilinx
>> ise, but i havn't tested it yet. I have not added the DAC driver to it
yet,
>> i'm not sure if this cpld is enough for these modules. here is the
>> implementation for RAM:
>> 
>
>You've written behavioral VHDL that describes a dual-port
>block RAM. That's lovely and all, but have you checked the CPLD
>datasheet and confirmed that there is a block RAM resource on the chip
>that will do that?  You could also write VHDL describing a unicorn, but
>you'd be hard pressed to make it pass synthesis.
>
>-- 
>Rob Gaddi, Highland Technology -- www.highlandtechnology.com
>Email address domain is currently out of order.  See above to fix.
>

I am some how obliged to use XC95144(since I have plenty of them purchased
before), and as it was mentioned here, I omitted RAM Module from my design
and instead I would like to add a SRAM or SDRAM chip,(and since SDRAM is
much cheaper than SRAM I'm apt to SDRAM), and here it posed another
question and  that is if this CPLD is capable of driving a SDRAM (regarding
dynamic memory timing constraints)?
tnx in advance for any helpful comment
Neda Baheri	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154306
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: jg <j.m.granville@gmail.com>
Date: Tue, 25 Sep 2012 04:23:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, September 25, 2012 11:09:14 PM UTC+12, nba83 wrote:
> I would like to add a SRAM or SDRAM chip,(and since SDRAM is
> much cheaper than SRAM I'm apt to SDRAM), and here it posed another

 SDRAM  is only cheaper than SRAM well above the 100 bytes you claimed to need.
For small storage, your RAM choices would be Parallel 256k bit (tends to be cheapest size), or you could look at the QuadSPI SRAM from Microchip.
 That is SO8, and can do 80MBit (20MHz x 4)
-jg

Article: 154307
Subject: Re: Multiple IDELAYCTRLs in V-5: how, and why?
From: Gabor <gabor@szakacs.invalid>
Date: Tue, 25 Sep 2012 09:00:04 -0400
Links: << >>  << T >>  << A >>
nospam@nospam.com wrote:
> I'm on Virtex-5, and have a lot of IODELAYs, for fixed and variable
> input delays. I've read chapter 7 of the User Guide, and AR #39966,
> about IODELAY_GROUPs. I need to instantiate one or more IDELAYCTRLs,
> and my options are (1) to instantiatiate one of them, and let the tool
> fix everything up, or (2) instantiate lots of them, and do it all by
> hand.
> 
> Here's the bit I don't understand. What's wrong with (1)? 
> 
> Page 342 of ug190 says "The most efficient way to use the IDELAYCTRL
> module is to define and lock down the placement of every IDELAYCTRL
> instance used in a design....Xilinx strongly recommends using
> IDELAYCTRL with a LOC constraint", but the UG doesn't seem to say
> anywhere why this is the case. What's the point? And why don't the
> tools just conenct up the IDELAYCTRLs anyway, without being told to?
> The IODELAY is useless without it.
> 
> Thanks. 
> 
> 
The IDELAYCTRL is one of the most poorly handled structures in the V5.
That being said, I believe the user guide was written before the
introduction of the IODELAY_GROUP to the tools.  Using groups is
the new "preferred" method.  In a simple system where you have only
one 200MHz reference clock and don't use the LOCK output of the
IDELAYCTRL, you can either use the original option (1) - one
IDELAYCTRL and no LOC constraint - or you can assign all IODELAYs
to the same IODELAY_GROUP.  If you're unfortunate enough to work on
an XPS / EDK design, then you might need to have multiple IODELAY_GROUP
constraints to avoid hand placement of all IDELAYCTRL's.

-- Gabor

Article: 154308
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: Tim Wescott <tim@seemywebsite.please>
Date: Tue, 25 Sep 2012 09:33:20 -0500
Links: << >>  << T >>  << A >>
On Tue, 25 Sep 2012 06:09:13 -0500, nba83 wrote:

>>On Mon, 24 Sep 2012 06:00:15 -0500 "nba83" <3224@embeddedrelated> wrote:
>>
>>> >On 09/24/2012 08:09 AM, nba83 wrote:
>>> >
>>> >> I want to feed data in parallel (8bit) to CPLD, buffer it for about
> 100
>>> >> bytes, and then start to drive SPI Out. I am some how concerned
> about
>>> the
>>> >> speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it
>>> >> is -10C(means 10nsec delay for IO routs), does this delay impose
>>> >> any
>>> problem?
>>> >> Since I want to drive the CPLD with 100MHZ oscillator clk input,
>>> >> and
> by
>>> clk
>>> >> dividing generate a 50 or 40MHz clk for SPI.
>>> >> tnx for any helpful comments :)
>>> >
>>> >The problem isn't going to be the speed, but where the CPLD is going
>>> >to
> 
>>> >store the 100 bytes. The XC95144XL only has 144 bits of storage
>>> >total.
>>> >
>>> >
>>> >
>>> I have implemented a 1k byte dual port ram in this cpld logic  in
> xilinx
>>> ise, but i havn't tested it yet. I have not added the DAC driver to it
> yet,
>>> i'm not sure if this cpld is enough for these modules. here is the
>>> implementation for RAM:
>>> 
>>> 
>>You've written behavioral VHDL that describes a dual-port block RAM.
>>That's lovely and all, but have you checked the CPLD datasheet and
>>confirmed that there is a block RAM resource on the chip that will do
>>that?  You could also write VHDL describing a unicorn, but you'd be hard
>>pressed to make it pass synthesis.
>>
>>--
>>Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email
>>address domain is currently out of order.  See above to fix.
>>
>>
> I am some how obliged to use XC95144(since I have plenty of them
> purchased before), and as it was mentioned here, I omitted RAM Module
> from my design and instead I would like to add a SRAM or SDRAM chip,(and
> since SDRAM is much cheaper than SRAM I'm apt to SDRAM), and here it
> posed another question and  that is if this CPLD is capable of driving a
> SDRAM (regarding dynamic memory timing constraints)?
> tnx in advance for any helpful comment Neda Baheri

It seems to me that you're rapidly approaching a point where your 
cheapest solution is to cast your XC95144s in a block of clear epoxy to 
hand out as a trophy, and switch to a microprocessor that's up to the 
task.

Do you really need to implement a FIFO in the CPLD?  Can't you just have 
the microprocessor write out the transaction (in parallel) each time you 
need it to come out the CPLD, thereby obviating the need or all the 
memory?

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

Article: 154309
Subject: Re: Getting in to the industry
From: jonesandy@comcast.net
Date: Tue, 25 Sep 2012 08:04:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
Having worked with many impressive college new-hire FPGA developers during =
my career, their main shortcoming is a lack of understanding how the develo=
pment process scales up from projects that a single designer or small team =
can execute in a few weeks, to larger projects that require many developers=
 (and even more verification engineers) several months to complete a single=
 generation of a progression of products. =20

They often do not yet understand the value of well-defined requirements (es=
pecially verifiable ones), and want to rush into coding before the overall =
design is far enough along.

Professional projects often involve multiple generations of a product, each=
 one incrementally improving upon the previous one. This places extreme imp=
ortance on planning, designing and coding for maintainability. It's not jus=
t about how few gates can run how fast.

Tools and techniques that are not often used in college projects include sc=
ripting everything so that results can be reliably repeated (by you and oth=
ers), as well as employing version control and change management (issue tra=
cking) tools.

In short, many new-hire (and a few experienced) FPGA developers lack the so=
ftware engineering expertise to successfully execute larger scale projects =
in industry. Luckily, most firms have experienced lead engineers to help ge=
t talented but inexperienced new-hires up to speed.

So, how can you prepare yourself?=20

Take a project, it does not have to be that large or complex, and write a d=
evelopment plan for it, including more than one version or generation of th=
e product. Include a summary schedule in your plan.=20

Write the requirements for the product as if you were not going to be the o=
ne developing (or verifying) it. Include a matrix that identifies which gen=
erations of the product have to meet which requirements. Do not write requi=
rements that prescribe how the product will do something; instead write req=
uirements for what the product must do, with observable criteria.=20

Write a verification plan (again, as if you were not going to be the one ve=
rifying it) with a matrix that shows how each requirement is going to be ve=
rified (simulation, analysis, test, inspection, etc.)=20

Write an Interface Control Document that defines the external interfaces. T=
his document should be heavily referenced by the design requirements.=20

Write a design document describing the module hierarchy and interfaces betw=
een them (this will be the basis for the coding phase); this is where you s=
tart describing the "how" you should have left out of the requirements. For=
 each module, summarize what the module needs to do; focus on the interface=
s, and only enough internal detail such that coding decisions do not impact=
 the interfaces.

Write a verification design document (similar to the design document, cover=
ing the verification models, tests, etc.) Make sure your verification does =
not include inspecting waveforms to see if a test passed, or comparing agai=
nst a set of "golden waveforms". All simulations should indicate in a log f=
ile whether or not each test passed.

Then, and only then, start coding your design. Start coding your simulation=
 environment. Then start testing your design (per your verification plan). =
Synthesize, place and route your design and verify timing and utilization r=
equirements.

When you are finished with the first generation of all of the above, write =
a design analysis report, summarizing and referencing the evidence from ver=
ification (simulation and analysis) that all of your requirements have been=
 satisfied. Every item in the verification matrix above should be covered i=
n the verification report.=20

Rinse and repeat for successive generations of the product.

Throughout all of the above, employ version control on all code, scripts an=
d documents. Emply issue-tracking tools to manage resolution of all defects=
 found during verification, including necessary changes to documents, scrip=
ts, RTL and testbench code. This may seem like overkill for a one-man proje=
ct. But you most likely will not be working professionally on one-man proje=
cts.

At the end of the project, write a project report. Include schedule perform=
ance (be honest!), and include "executive summaries" of the design analysis=
 report(s), issue tracking metrics (especially graphs over time showing ope=
n and closed defects

Your probably thinking; "Wow, that's a lot of writing and not a lot of codi=
ng!" Your right, designing (especially with large projects) is about a lot =
more than coding.

Naturally, to complete all of this in a reasonable time, the product itself=
 will probably have to be pretty small/simple. But going through the proces=
s, and being able to talk about it with with a prospective employer during =
an interview, will impress a prosepective employer. By demonstrating that y=
ou have thought and planned all of this out, and then executed it, you will=
 be demonstrating to your prospective employer that you have at least an bi=
t of an understanding of what it takes to develop FPGAs professionally. Kee=
p in mind that your prospective employer will likely have their own process=
, tools, documentation standards, etc. (i.e. their own process standards) t=
hat may not match yours that closely, but the basic elements will be pretty=
 similar, and your mastery of your own well thought out process will prepar=
e you to master theirs.

Andy

Article: 154310
Subject: Re: Getting in to the industry
From: hamilton <hamilton@nothere.com>
Date: Tue, 25 Sep 2012 09:16:59 -0600
Links: << >>  << T >>  << A >>
On 9/25/2012 9:04 AM, jonesandy@comcast.net wrote:
> Having worked with many impressive college new-hire FPGA developers during my career, their main shortcoming is a lack of understanding how the development process scales up from projects that a single designer or small team can execute in a few weeks, to larger projects that require many developers (and even more verification engineers) several months to complete a single generation of a progression of products.
>
> They often do not yet understand the value of well-defined requirements (especially verifiable ones), and want to rush into coding before the overall design is far enough along.
>
> Professional projects often involve multiple generations of a product, each one incrementally improving upon the previous one. This places extreme importance on planning, designing and coding for maintainability. It's not just about how few gates can run how fast.
>
> Tools and techniques that are not often used in college projects include scripting everything so that results can be reliably repeated (by you and others), as well as employing version control and change management (issue tracking) tools.
>
> In short, many new-hire (and a few experienced) FPGA developers lack the software engineering expertise to successfully execute larger scale projects in industry. Luckily, most firms have experienced lead engineers to help get talented but inexperienced new-hires up to speed.
>
> So, how can you prepare yourself?

This is but one industry requirement.

Most companies are small 2-3 man operations that require "Get it done, 
NOW" day to day functions.

I have worked for large companies that required lots of people and lots 
of documentation.

Most companies I have consulted for were looking for a lone gun to "Get 
it done. NOW".

College courses are like small companies, needs to get it done before 
the end of the semester.



>
> Take a project, it does not have to be that large or complex, and write a development plan for it, including more than one version or generation of the product. Include a summary schedule in your plan.
>
> Write the requirements for the product as if you were not going to be the one developing (or verifying) it. Include a matrix that identifies which generations of the product have to meet which requirements. Do not write requirements that prescribe how the product will do something; instead write requirements for what the product must do, with observable criteria.
>
> Write a verification plan (again, as if you were not going to be the one verifying it) with a matrix that shows how each requirement is going to be verified (simulation, analysis, test, inspection, etc.)
>
> Write an Interface Control Document that defines the external interfaces. This document should be heavily referenced by the design requirements.
>
> Write a design document describing the module hierarchy and interfaces between them (this will be the basis for the coding phase); this is where you start describing the "how" you should have left out of the requirements. For each module, summarize what the module needs to do; focus on the interfaces, and only enough internal detail such that coding decisions do not impact the interfaces.
>
> Write a verification design document (similar to the design document, covering the verification models, tests, etc.) Make sure your verification does not include inspecting waveforms to see if a test passed, or comparing against a set of "golden waveforms". All simulations should indicate in a log file whether or not each test passed.
>
> Then, and only then, start coding your design. Start coding your simulation environment. Then start testing your design (per your verification plan). Synthesize, place and route your design and verify timing and utilization requirements.
>
> When you are finished with the first generation of all of the above, write a design analysis report, summarizing and referencing the evidence from verification (simulation and analysis) that all of your requirements have been satisfied. Every item in the verification matrix above should be covered in the verification report.
>
> Rinse and repeat for successive generations of the product.
>
> Throughout all of the above, employ version control on all code, scripts and documents. Emply issue-tracking tools to manage resolution of all defects found during verification, including necessary changes to documents, scripts, RTL and testbench code. This may seem like overkill for a one-man project. But you most likely will not be working professionally on one-man projects.
>
> At the end of the project, write a project report. Include schedule performance (be honest!), and include "executive summaries" of the design analysis report(s), issue tracking metrics (especially graphs over time showing open and closed defects
>
> Your probably thinking; "Wow, that's a lot of writing and not a lot of coding!" Your right, designing (especially with large projects) is about a lot more than coding.
>
> Naturally, to complete all of this in a reasonable time, the product itself will probably have to be pretty small/simple. But going through the process, and being able to talk about it with with a prospective employer during an interview, will impress a prosepective employer. By demonstrating that you have thought and planned all of this out, and then executed it, you will be demonstrating to your prospective employer that you have at least an bit of an understanding of what it takes to develop FPGAs professionally. Keep in mind that your prospective employer will likely have their own process, tools, documentation standards, etc. (i.e. their own process standards) that may not match yours that closely, but the basic elements will be pretty similar, and your mastery of your own well thought out process will prepare you to master theirs.
>
> Andy
>


Article: 154311
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: "nba83" <3224@embeddedrelated>
Date: Wed, 26 Sep 2012 00:01:48 -0500
Links: << >>  << T >>  << A >>

>Do you really need to implement a FIFO in the CPLD?  Can't you just have 
>the microprocessor write out the transaction (in parallel) each time you 
>need it to come out the CPLD, thereby obviating the need or all the 
>memory?
>
>-- 
>Tim Wescott
>Control system and signal processing consulting
>www.wescottdesign.com
>

the microprocessor is ARM Corex M3(Stm32f107) which has really slow IOs,
writing 16 bits, setting and resetting a control pin takes about 1Usec, I
need to transfer 8ch*16bit within 5 usec, so I need to buffer data
somewhere outside microprocessor. I'm in the design phase of project
prototype, and I want to consider any cheap available option in the board,
in software development phase some of the chips may be omitted.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154312
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Wed, 26 Sep 2012 12:42:42 +0200
Links: << >>  << T >>  << A >>
In comp.arch.fpga,
nba83 <3224@embeddedrelated> wrote:
>
>>Do you really need to implement a FIFO in the CPLD?  Can't you just have 
>>the microprocessor write out the transaction (in parallel) each time you 
>>need it to come out the CPLD, thereby obviating the need or all the 
>>memory?
>>
>
> the microprocessor is ARM Corex M3(Stm32f107) which has really slow IOs,
> writing 16 bits, setting and resetting a control pin takes about 1Usec, I
> need to transfer 8ch*16bit within 5 usec, so I need to buffer data
> somewhere outside microprocessor. I'm in the design phase of project
> prototype, and I want to consider any cheap available option in the board,
> in software development phase some of the chips may be omitted.	   

Are you bitbanging this? Seems the STM32F107 has an I2S interface and so
has the AD1933. Aren't the two working together, or is the another reason 
you can not use the I2S peripheral?

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

I sometimes think that God, in creating man, somewhat overestimated his ability.
		-- Oscar Wilde

Article: 154313
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: "nba83" <3224@embeddedrelated>
Date: Wed, 26 Sep 2012 11:49:32 -0500
Links: << >>  << T >>  << A >>

>Are you bitbanging this? Seems the STM32F107 has an I2S interface and so
>has the AD1933. Aren't the two working together, or is the another reason

>you can not use the I2S peripheral?
>
		
>
Stm32 only supports rates 8 KHz to 96 KHz, I want to drive the chip at 192
KHz
 which Stm does not provide	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154314
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: Tim Wescott <tim@seemywebsite.com>
Date: Wed, 26 Sep 2012 13:41:35 -0500
Links: << >>  << T >>  << A >>
On Wed, 26 Sep 2012 11:49:32 -0500, nba83 wrote:

>>Are you bitbanging this? Seems the STM32F107 has an I2S interface and so
>>has the AD1933. Aren't the two working together, or is the another
>>reason
> 
>>you can not use the I2S peripheral?
>>
>>
> 		
> Stm32 only supports rates 8 KHz to 96 KHz, I want to drive the chip at
> 192 KHz
>  which Stm does not provide

Things aren't lining up here.

192kHz sampling?  Over 35MHz bit rate?  That works out to over 182bits/
sample.  How many bits per channel?  How many channels?

That chip will run at something like a 72MHz core clock, which gives you 
36MHz at the SPI.  Moreover, if the ADC demands (say) 32 bits/write, then 
you've got 64 clock cycles per word out if the chip is running flat out 
-- that leads me to believe that if you can't pump this out the SPI port 
of that chip, you're not going to be able to do anything significant to 
the data while it's in the processor.  Unless (and probably even if) you 
hand-code the thing in assembly and run it out of RAM, you're not going 
to be able to do much more than read the data out of memory and shove it 
out the door.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Article: 154315
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: "langwadt@fonz.dk" <langwadt@fonz.dk>
Date: Wed, 26 Sep 2012 12:02:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 26, 8:41=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Wed, 26 Sep 2012 11:49:32 -0500, nba83 wrote:
> >>Are you bitbanging this? Seems the STM32F107 has an I2S interface and s=
o
> >>has the AD1933. Aren't the two working together, or is the another
> >>reason
>
> >>you can not use the I2S peripheral?
>
> > Stm32 only supports rates 8 KHz to 96 KHz, I want to drive the chip at
> > 192 KHz
> > =A0which Stm does not provide
>
> Things aren't lining up here.
>
> 192kHz sampling? =A0Over 35MHz bit rate? =A0That works out to over 182bit=
s/
> sample. =A0How many bits per channel? =A0How many channels?
>

first post mentioned ad1933, 8channels,24bit,192kHz so 36.864MHz

> That chip will run at something like a 72MHz core clock, which gives you
> 36MHz at the SPI. =A0Moreover, if the ADC demands (say) 32 bits/write, th=
en
> you've got 64 clock cycles per word out if the chip is running flat out
> -- that leads me to believe that if you can't pump this out the SPI port
> of that chip, you're not going to be able to do anything significant to
> the data while it's in the processor. =A0Unless (and probably even if) yo=
u
> hand-code the thing in assembly and run it out of RAM, you're not going
> to be able to do much more than read the data out of memory and shove it
> out the door.

SPI is just for setup, data goes on I2S, running the mcu at 73.728MHz
and
using DMA it might work (assuming the I2S can run at mcuclk/2)

-Lasse

Article: 154316
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: nico@puntnl.niks (Nico Coesel)
Date: Wed, 26 Sep 2012 23:06:03 GMT
Links: << >>  << T >>  << A >>
"nba83" <3224@embeddedrelated> wrote:

>>On Mon, 24 Sep 2012 06:00:15 -0500
>>"nba83" <3224@embeddedrelated> wrote:
>>
>>> >On 09/24/2012 08:09 AM, nba83 wrote:
>>> >
>>> >> I want to feed data in parallel (8bit) to CPLD, buffer it for about
>100
>>> >> bytes, and then start to drive SPI Out. I am some how concerned
>about
>>> the
>>> >> speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it is
>>> >> -10C(means 10nsec delay for IO routs), does this delay impose any
>>> problem?
>>> >> Since I want to drive the CPLD with 100MHZ oscillator clk input, and
>by
>>> 
>>
>>You've written behavioral VHDL that describes a dual-port
>>block RAM. That's lovely and all, but have you checked the CPLD
>>datasheet and confirmed that there is a block RAM resource on the chip
>>that will do that?  You could also write VHDL describing a unicorn, but
>>you'd be hard pressed to make it pass synthesis.
>>
>>-- 
>>Rob Gaddi, Highland Technology -- www.highlandtechnology.com
>>Email address domain is currently out of order.  See above to fix.
>>
>
>I am some how obliged to use XC95144(since I have plenty of them purchased
>before), and as it was mentioned here, I omitted RAM Module from my design
>and instead I would like to add a SRAM or SDRAM chip,(and since SDRAM is
>much cheaper than SRAM I'm apt to SDRAM), and here it posed another
>question and  that is if this CPLD is capable of driving a SDRAM (regarding
>dynamic memory timing constraints)?

I'd go for SRAM. I have used the XC95144 for replacing CRT / STN
displays with TFT. The key is to calculate the required bandwidth. In
my most recent project I used a 16 bit SRAM.

Still, given your project requirements you probably could get by with
a small FIFO (maybe 4 bytes deep). You need to get enough data from
the microcontroller. OTOH it sounds like a lot of fuss to keep the
microcontroller. If you switch to an ARM device (NXP for instance) you
can reach >30MHz SPI easely and use DMA.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 154317
Subject: Re: Global Reset using Global Buffer
From: Christopher Head <chead@is.invalid>
Date: Thu, 27 Sep 2012 00:36:20 -0700
Links: << >>  << T >>  << A >>
Awesome, thanks! Seems to me this makes it a lot easier to reason
about: you just give every variable or signal an initial value which is
loaded during bitstream load and let the configuration-clock-based GSR
handling deal with the rest. Make sure PLLs and DCMs start up after GSR
is deasserted and that everything uses a clock downstream of a PLL or
DCM (and perhaps introduce some BUFGCEs) and everything should be OK—at
least, for my application it’s easy enough to things that way. Clock
domain crossings might come up in either order, but that’s pretty easy
to deal with.

Chris

On Wed, 19 Sep 2012 16:06:58 +0000 (UTC)
Brian Drummond <brian@shapes.demon.co.uk> wrote:

> On Wed, 19 Sep 2012 09:50:35 -0500, jt_eaton wrote:
> 
> >>On Wed, 19 Sep 2012 00:15:52 -0700, Christopher Head wrote:
> 
> >>> As far as issues of different FFs leaving reset on different clock
> >>> cycles are concerned, could one not solve these issues by
> >>> asserting GSR for long enough to reset all FFs, deassert it, then
> >>> activate the clocks afterwards?
> >>
> >>Yes. Perhaps better, activate clock enable(s) afterwards.
> >>
> >>Either way, you may need a hierarchy of clock activation; after
> >>reset, you don't want your main clock generator to wait for several
> >>cycles of a (stopped) clock...
> >>
> >>- Brian
> >>
> >>
> > Guys,
> > 
> > You don't need to stop the clock at all. The reset deassert to clock
> > edge spec only applies when you are trying to change state. 
> 
> I know. But I was being a little facetious, after one occasion when I 
> shot myself in the foot with a synchronous reset for a DLL...
> 
> - Brian



Article: 154318
Subject: Re: edge matching
From: fpgasm <user@domain.com>
Date: Thu, 27 Sep 2012 06:01:35 -0700
Links: << >>  << T >>  << A >>
First of all, experts recomend double-flopping the inputs to avoid 
metastability.

If you look at implementations of asynchronous protocols - say RS232 - 
you will see that generally you need to oversample.  With a clock 16 
times maximum baud rate, RS232 circuits have a good chance  of catching 
transitions and being able to sync up.

If you have multiple sources, you can run a fast clock and flop in the 
signals, then compare them at some later time.

rohitbisht wrote:
> Hello
>
> 1. I'am a beginner in fpga.and want some help.
> I'am trying to write code for matching rising edges of two different pulse
> train signa,so that AND operation can be performed b/w them .
> synchronization is must for carrying the AND  operation.Kindly suggest some
> idea.
>
> 2.how is it possible to generate signals at every rising egde of a given
> signal where the frequency of new signal is defined by the taking (present
> and just previous rising egde)for frequency calculation and new signal will
> be generated at this present rising edge of given signal '
>
> seeking your valuable ideas.
>
> thanks in advance.
>
> regards
>
> 	
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com
>


-- 
Explore the FPGA with fpgasm, the assembler for FPGAs Read

Article: 154319
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: Tim Wescott <tim@seemywebsite.com>
Date: Thu, 27 Sep 2012 11:45:41 -0500
Links: << >>  << T >>  << A >>
On Wed, 26 Sep 2012 23:06:03 +0000, Nico Coesel wrote:

> "nba83" <3224@embeddedrelated> wrote:
> 
>>>On Mon, 24 Sep 2012 06:00:15 -0500
>>>"nba83" <3224@embeddedrelated> wrote:
>>>
>>>> >On 09/24/2012 08:09 AM, nba83 wrote:
>>>> >
>>>> >> I want to feed data in parallel (8bit) to CPLD, buffer it for
>>>> >> about
>>100
>>>> >> bytes, and then start to drive SPI Out. I am some how concerned
>>about
>>>> the
>>>> >> speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it
>>>> >> is -10C(means 10nsec delay for IO routs), does this delay impose
>>>> >> any
>>>> problem?
>>>> >> Since I want to drive the CPLD with 100MHZ oscillator clk input,
>>>> >> and
>>by
>>>> 
>>>> 
>>>You've written behavioral VHDL that describes a dual-port block RAM.
>>>That's lovely and all, but have you checked the CPLD datasheet and
>>>confirmed that there is a block RAM resource on the chip that will do
>>>that?  You could also write VHDL describing a unicorn, but you'd be
>>>hard pressed to make it pass synthesis.
>>>
>>>--
>>>Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email
>>>address domain is currently out of order.  See above to fix.
>>>
>>>
>>I am some how obliged to use XC95144(since I have plenty of them
>>purchased before), and as it was mentioned here, I omitted RAM Module
>>from my design and instead I would like to add a SRAM or SDRAM chip,(and
>>since SDRAM is much cheaper than SRAM I'm apt to SDRAM), and here it
>>posed another question and  that is if this CPLD is capable of driving a
>>SDRAM (regarding dynamic memory timing constraints)?
> 
> I'd go for SRAM. I have used the XC95144 for replacing CRT / STN
> displays with TFT. The key is to calculate the required bandwidth. In my
> most recent project I used a 16 bit SRAM.
> 
> Still, given your project requirements you probably could get by with a
> small FIFO (maybe 4 bytes deep). You need to get enough data from the
> microcontroller. OTOH it sounds like a lot of fuss to keep the
> microcontroller. If you switch to an ARM device (NXP for instance) you
> can reach >30MHz SPI easely and use DMA.

He's using an STM32F107 which _is_ an ARM Cortex, and he's claiming to 
need more than 35MHz.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Article: 154320
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 27 Sep 2012 19:54:08 GMT
Links: << >>  << T >>  << A >>
Tim Wescott <tim@seemywebsite.com> wrote:

>On Wed, 26 Sep 2012 23:06:03 +0000, Nico Coesel wrote:
>
>> "nba83" <3224@embeddedrelated> wrote:
>> 
>>>>On Mon, 24 Sep 2012 06:00:15 -0500
>>>>"nba83" <3224@embeddedrelated> wrote:
>>>>
>>>>> >On 09/24/2012 08:09 AM, nba83 wrote:
>>>>> >
>>>>> >> I want to feed data in parallel (8bit) to CPLD, buffer it for
>>>>> >> about
>>>100
>>>>> >> bytes, and then start to drive SPI Out. I am some how concerned
>>>about
>>>>> the
>>>>> >> speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it
>>>>> >> is -10C(means 10nsec delay for IO routs), does this delay impose
>>>>> >> any
>>>>> problem?
>>>>> >> Since I want to drive the CPLD with 100MHZ oscillator clk input,
>>>>> >> and
>>>by
>>>>> 
>>>>> 
>>>>You've written behavioral VHDL that describes a dual-port block RAM.
>>>>That's lovely and all, but have you checked the CPLD datasheet and
>>>>confirmed that there is a block RAM resource on the chip that will do
>>>>that?  You could also write VHDL describing a unicorn, but you'd be
>>>>hard pressed to make it pass synthesis.
>>>>
>>>>--
>>>>Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email
>>>>address domain is currently out of order.  See above to fix.
>>>>
>>>>
>>>I am some how obliged to use XC95144(since I have plenty of them
>>>purchased before), and as it was mentioned here, I omitted RAM Module
>>>from my design and instead I would like to add a SRAM or SDRAM chip,(and
>>>since SDRAM is much cheaper than SRAM I'm apt to SDRAM), and here it
>>>posed another question and  that is if this CPLD is capable of driving a
>>>SDRAM (regarding dynamic memory timing constraints)?
>> 
>> I'd go for SRAM. I have used the XC95144 for replacing CRT / STN
>> displays with TFT. The key is to calculate the required bandwidth. In my
>> most recent project I used a 16 bit SRAM.
>> 
>> Still, given your project requirements you probably could get by with a
>> small FIFO (maybe 4 bytes deep). You need to get enough data from the
>> microcontroller. OTOH it sounds like a lot of fuss to keep the
>> microcontroller. If you switch to an ARM device (NXP for instance) you
>> can reach >30MHz SPI easely and use DMA.
>
>He's using an STM32F107 which _is_ an ARM Cortex, and he's claiming to 
>need more than 35MHz.

I guess ST is still making mediocre controllers. After an adventure
with the STR700 series I switched to NXP and never looked back at ST.
Appearantly a good choice :-)

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 154321
Subject: Replacing Logic with an FPGA/CPLD in a 510K device.
From: hamilton <hamilton@nothere.com>
Date: Thu, 27 Sep 2012 15:26:20 -0600
Links: << >>  << T >>  << A >>
Does anyone have some good links on FDA requirements for replacing TTL 
logic with an FPGA/CPLD ?

This is for a Class 3 device.

Does the FPGA/CPLD design files constitute "firmware" and needs to be 
tested the same way as firmware ?

Thank you

hamilton

Article: 154322
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: Tim Wescott <tim@seemywebsite.com>
Date: Thu, 27 Sep 2012 17:19:01 -0500
Links: << >>  << T >>  << A >>
On Thu, 27 Sep 2012 19:54:08 +0000, Nico Coesel wrote:

> Tim Wescott <tim@seemywebsite.com> wrote:
> 
>>On Wed, 26 Sep 2012 23:06:03 +0000, Nico Coesel wrote:
>>
>>> "nba83" <3224@embeddedrelated> wrote:
>>> 
>>>>>On Mon, 24 Sep 2012 06:00:15 -0500
>>>>>"nba83" <3224@embeddedrelated> wrote:
>>>>>
>>>>>> >On 09/24/2012 08:09 AM, nba83 wrote:
>>>>>> >
>>>>>> >> I want to feed data in parallel (8bit) to CPLD, buffer it for
>>>>>> >> about
>>>>100
>>>>>> >> bytes, and then start to drive SPI Out. I am some how concerned
>>>>about
>>>>>> the
>>>>>> >> speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C),
>>>>>> >> it is -10C(means 10nsec delay for IO routs), does this delay
>>>>>> >> impose any
>>>>>> problem?
>>>>>> >> Since I want to drive the CPLD with 100MHZ oscillator clk input,
>>>>>> >> and
>>>>by
>>>>>> 
>>>>>> 
>>>>>You've written behavioral VHDL that describes a dual-port block RAM.
>>>>>That's lovely and all, but have you checked the CPLD datasheet and
>>>>>confirmed that there is a block RAM resource on the chip that will do
>>>>>that?  You could also write VHDL describing a unicorn, but you'd be
>>>>>hard pressed to make it pass synthesis.
>>>>>
>>>>>--
>>>>>Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email
>>>>>address domain is currently out of order.  See above to fix.
>>>>>
>>>>>
>>>>I am some how obliged to use XC95144(since I have plenty of them
>>>>purchased before), and as it was mentioned here, I omitted RAM Module
>>>>from my design and instead I would like to add a SRAM or SDRAM
>>>>chip,(and since SDRAM is much cheaper than SRAM I'm apt to SDRAM), and
>>>>here it posed another question and  that is if this CPLD is capable of
>>>>driving a SDRAM (regarding dynamic memory timing constraints)?
>>> 
>>> I'd go for SRAM. I have used the XC95144 for replacing CRT / STN
>>> displays with TFT. The key is to calculate the required bandwidth. In
>>> my most recent project I used a 16 bit SRAM.
>>> 
>>> Still, given your project requirements you probably could get by with
>>> a small FIFO (maybe 4 bytes deep). You need to get enough data from
>>> the microcontroller. OTOH it sounds like a lot of fuss to keep the
>>> microcontroller. If you switch to an ARM device (NXP for instance) you
>>> can reach >30MHz SPI easely and use DMA.
>>
>>He's using an STM32F107 which _is_ an ARM Cortex, and he's claiming to
>>need more than 35MHz.
> 
> I guess ST is still making mediocre controllers. After an adventure with
> the STR700 series I switched to NXP and never looked back at ST.
> Appearantly a good choice :-)

35MHz clock at the peripheral -- the ST chip he's looking at is rated for 
70 or 72MHz or some such.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Article: 154323
Subject: Re: Xilinx CPLD XC95144 for Driving Sigma Delta DAC
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 28 Sep 2012 00:54:34 GMT
Links: << >>  << T >>  << A >>
Tim Wescott <tim@seemywebsite.com> wrote:

>On Thu, 27 Sep 2012 19:54:08 +0000, Nico Coesel wrote:
>
>> Tim Wescott <tim@seemywebsite.com> wrote:
>> 
>>>On Wed, 26 Sep 2012 23:06:03 +0000, Nico Coesel wrote:
>>>
>>>> "nba83" <3224@embeddedrelated> wrote:
>>>> 
>>>>>>On Mon, 24 Sep 2012 06:00:15 -0500
>>>>>>"nba83" <3224@embeddedrelated> wrote:
>>>>>>
>>>>>>> >On 09/24/2012 08:09 AM, nba83 wrote:
>>>>>>> >
>>>>>>> >> I want to feed data in parallel (8bit) to CPLD, buffer it for
>>>>>>> >> about
>>>>>100
>>>>>>> >> bytes, and then start to drive SPI Out. I am some how concerned
>>>>>about
>>>>>>> the
>>>> 
>>>> Still, given your project requirements you probably could get by with
>>>> a small FIFO (maybe 4 bytes deep). You need to get enough data from
>>>> the microcontroller. OTOH it sounds like a lot of fuss to keep the
>>>> microcontroller. If you switch to an ARM device (NXP for instance) you
>>>> can reach >30MHz SPI easely and use DMA.
>>>
>>>He's using an STM32F107 which _is_ an ARM Cortex, and he's claiming to
>>>need more than 35MHz.
>> 
>> I guess ST is still making mediocre controllers. After an adventure with
>> the STR700 series I switched to NXP and never looked back at ST.
>> Appearantly a good choice :-)
>
>35MHz clock at the peripheral -- the ST chip he's looking at is rated for 
>70 or 72MHz or some such.

AFAIK most ST devices can't run from flash at their rated clock
speeds. NXP's can and some go up to 120MHz (180MHz is on its way)!

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 154324
Subject: Re: Replacing Logic with an FPGA/CPLD in a 510K device.
From: Gabor <gabor@szakacs.org>
Date: Thu, 27 Sep 2012 21:59:34 -0400
Links: << >>  << T >>  << A >>
On 9/27/2012 5:26 PM, hamilton wrote:
> Does anyone have some good links on FDA requirements for replacing TTL
> logic with an FPGA/CPLD ?
>
> This is for a Class 3 device.
>
> Does the FPGA/CPLD design files constitute "firmware" and needs to be
> tested the same way as firmware ?
>
> Thank you
>
> hamilton

I'm not sure if you've seen this, but Mentor has a white paper
here:

http://www.mentor.com/products/fpga/resources/overview/best-practice-development-processes-for-medical-device-fpgas-ec7f7922-2326-48e2-a8ea-626ab0804b0f

http://www.mentor.com/resources/techpubs/upload/mentorpaper_68961.pdf

It talks about a lack of specific standards in the hardware development
process, and how to go about ensuring quality using techniques borrowed
from other hi-rel fields like aerospace.  It no doubt recommends an
approach that requires plenty of their verification tools...

-- Gabor



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