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 91725

Article: 91725
Subject: Re: fastest possible USB
From: "Nial Stewart" <nial@nialstewartdevelopments.co.uk>
Date: Fri, 11 Nov 2005 10:02:56 -0000
Links: << >>  << T >>  << A >>
> Hi
> Does anyone have some advice for the fastest say to get many MBytes of
> data from a Spartan3 fifo to the hard disk of a PC via usb. I assume
> that it is a combination of the best USB interface next to the FPGA and
> perhaps a USB chipset in the PC that can do some very clever DMA.
> I don't want to mess with custom RAID stuff I just want to dump it to a
> standard hard disk & controller.
> Any pointers appreciated.
> Colin


Colin,

I think a PCI interface capable of bus mastering will still be faster than
a USB2.0 interface.

The PCI performance is slightly un-deterministic as it depends what else is
on your bus, but from what I've read here over the years I think 80MB/s is
a reasonable expectation.

I half remember reading that although USB 2.0 gives you 460(?) Mb/s that
this doesn't directly translate ~ 460/8 MB/s of data through-put (ie 60MB/s).


Nial.


-------------------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk 



Article: 91726
Subject: Re: Bus for Spartan3
From: "Marco" <marco@marylon.com>
Date: 11 Nov 2005 02:12:38 -0800
Links: << >>  << T >>  << A >>
Thanks to you all, ciao


Article: 91727
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 11 Nov 2005 10:22:14 +0000
Links: << >>  << T >>  << A >>
air_bits@yahoo.com writes:


> Anybody else have pet ideas, suggestions, or wish-list items that
> a C based HLL/HDL tool should handle?
> 

I had a quick play the other day and I noticed that the counter
example generates it's own set of lookup-tables for the increment
logic, creating an enormous VHDL file.  I imagine the code generator
could be simplified somewhat to take advantage of modern
synthesis... writing a process with x:=x+1 in!

My personal wishes for it would be 

a) you can "simulate" the code with a suitable wrapper using a normal
C-compiler

b) you can explicitly parallelise stuff within a given function

c) some form of communication is provided between processes, that also
simulates in boggo-C.  Something like Occam channels or FSL ports
would be my preference

Cheers,
Martin


-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt  
   

Article: 91728
Subject: Re: open-sourced FPGA (vhdl, verilog, C variants) design libraries, working toward a GNU (for hardware) paradigm
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 11 Nov 2005 10:34:41 +0000
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> writes:

<snip>
> It generally
> does take someone seasoned to turn out an FPGA design that uses the
> resources somewhat efficiently, that is going to be reliable, and that
> isn't going to spend a large part of the time to market in some lab
> chasing down countless naive design errors.

My comments are not aimed at Ray in particular, but I thought I would
just note that that's true of embedded software also.  Surely the
point is that doing things efficiently and reliably (especially in
resource limited environments) is Not Easy and you have to have
competent (or better, depending on the project!) people doing it.

They also need good tools to do the job.  Personally I'd love to get
away from writing low-level VHDL for *some* of the things I do, but I
wouldn't fancy writing an SDRAM controller in a C-like HDL either.

There's a phrase involving hammers and nails that springs to mind...

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt  
   

Article: 91729
Subject: Re: fastest possible USB
From: Mike Harrison <mike@whitewing.co.uk>
Date: Fri, 11 Nov 2005 11:45:12 GMT
Links: << >>  << T >>  << A >>
On 11 Nov 2005 01:07:38 -0800, "colin" <colin_toogood@yahoo.com> wrote:

>Hi
>
>Does anyone have some advice for the fastest say to get many MBytes of
>data from a Spartan3 fifo to the hard disk of a PC via usb. I assume
>that it is a combination of the best USB interface next to the FPGA and
>perhaps a USB chipset in the PC that can do some very clever DMA.
>I don't want to mess with custom RAID stuff I just want to dump it to a
>standard hard disk & controller.
>
>Any pointers appreciated.
>
>Colin

Something else you may want to think about is a dual-port interface to an extarnal USB2  HD, i.e.
FPGA to IDE, and IDE to USB2 using one of the standard chips available for this. This would have the
advantage of more deterministic timing and probably higher throughput.


Article: 91730
Subject: Re: What does the IP in IPCORE stand for? (say "gateware" instead)
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 11 Nov 2005 03:51:34 -0800
Links: << >>  << T >>  << A >>

"Adam Megacz" <megacz@cs.berkeley.edu> wrote in message 
news:x1fyq6mx8i.fsf_-_@nowhere.com...
>
> "IP Core" is often [mis]used even when the writer does not mean to
> exclude public domain or open source works.  For this reason, the term
> "gateware" is preferred unless you intend to deliberately exclude
> noncommercial creations.
>
>  http://en.wikipedia.org/wiki/Gateware
>
Hi Adam,
Did you just make up that word? A quick search of C.A.F. in Google groups 
gave me a grand total of 4 hits. I wouldn't call that 'preferred'! I also 
note that the Wikipedia discussion page is somewhat negative on this usage, 
saying it's probably a candidate for deletion. The most non-C.A.F. Google 
hits for it seem to be for software in network gateways. I could find no 
mention of it anywhere on opencores.org.
Best, Syms. 



Article: 91731
Subject: Re: fastest possible USB
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Fri, 11 Nov 2005 12:51:51 -0000
Links: << >>  << T >>  << A >>
I'll add to that and say that the USB controller in the PC is probably 
sitting on a PCI bus or at least affected by the traffic on it. Also worth 
saying fastest USB is 480 MBit/s excluding overheads and 32bit/33MHz PCI is 
1056 MBit/s excluding overheads.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development 
Board.
http://www.enterpoint.co.uk


"Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote in message 
news:43746c57$0$355$da0feed9@news.zen.co.uk...
>> Hi
>> Does anyone have some advice for the fastest say to get many MBytes of
>> data from a Spartan3 fifo to the hard disk of a PC via usb. I assume
>> that it is a combination of the best USB interface next to the FPGA and
>> perhaps a USB chipset in the PC that can do some very clever DMA.
>> I don't want to mess with custom RAID stuff I just want to dump it to a
>> standard hard disk & controller.
>> Any pointers appreciated.
>> Colin
>
>
> Colin,
>
> I think a PCI interface capable of bus mastering will still be faster than
> a USB2.0 interface.
>
> The PCI performance is slightly un-deterministic as it depends what else 
> is
> on your bus, but from what I've read here over the years I think 80MB/s is
> a reasonable expectation.
>
> I half remember reading that although USB 2.0 gives you 460(?) Mb/s that
> this doesn't directly translate ~ 460/8 MB/s of data through-put (ie 
> 60MB/s).
>
>
> Nial.
>
>
> -------------------------------------------------------------
> Nial Stewart Developments Ltd
> FPGA and High Speed Digital Design
> www.nialstewartdevelopments.co.uk
> 



Article: 91732
Subject: MicroBlaze Seminar UK
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Fri, 11 Nov 2005 13:17:56 -0000
Links: << >>  << T >>  << A >>
For all that are interested we have some free lunchtime seminars, and 
following optional lab, based on using and building up a MicroBlaze 
microprocessor design.

Some initial basic details here 
http://www.enterpoint.co.uk/seminar/seminar.html. There are 2 dates 
confirmed (Malvern and Warwick) so far in the UK and probably 2 more TBA. If 
someone has a good suggestion for a location elsewhere in europe let me know 
and I will see if it can be added to the schedule.

John Adair
Enterpoint Ltd. - Home of Raggedstone1. The Cheap Spartan3 PCI Development 
Board.
http://www.enterpoint.co.uk



Article: 91733
Subject: Re: Is this even true???
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Fri, 11 Nov 2005 13:39:18 GMT
Links: << >>  << T >>  << A >>
"Ray Andraka" <ray@andraka.com> wrote in message 
news:F0Scf.2230$Mi5.2093@dukeread07...
> This is true provided you access every single row,
> well at least every row you have data in, within
> the refresh time. This can be used to advantage in video frame buffers, 
> for example as long as the frame time does not exceed the refresh time.
> So yes, it can be useful.  It doesn't save a lot of memory bandwidth or 
> time, but it can substantially simplify the DRAM controller in your 
> design.

Good point.

The BBC micro interleaved access with the 6845 CRTC, and the regular 
sequential video accesses did the refresh.




Article: 91734
Subject: Re: fastest possible USB
From: Steven Derrien <sderrienREMOVE@irisa.fr>
Date: Fri, 11 Nov 2005 14:48:54 +0100
Links: << >>  << T >>  << A >>
colin a écrit :
> Hi
> 
> Does anyone have some advice for the fastest say to get many MBytes of
> data from a Spartan3 fifo to the hard disk of a PC via usb. I assume
> that it is a combination of the best USB interface next to the FPGA and
> perhaps a USB chipset in the PC that can do some very clever DMA.
> I don't want to mess with custom RAID stuff I just want to dump it to a
> standard hard disk & controller.

My two cents :

You might instead consider implementing a simple IDE hardware interface, 
the protocol is quite straighforward if you stick to PIO mode (no DMA, 
however you can reach almost 15 Mbytes/sec, which is close from what
you usuallay with an USB drive).

The amount of effort needed to implement the IDE interface might 
actually be lower than trying to interface with an external USB bridge

Here is a link to a open-source IDE controller IP core

http://www.opencores.org/projects.cgi/web/ata/overview

I don't know how efficient it is (we rolled our own).

Hope it can help ...

Steven

> 
> Any pointers appreciated.
> 
> Colin
> 

Article: 91735
Subject: Re: How do i detect ethernet frames of layer 2 using ethereal?
From: "jai.dhar@gmail.com" <jai.dhar@gmail.com>
Date: 11 Nov 2005 06:09:13 -0800
Links: << >>  << T >>  << A >>
Definitely use a crossover for this kind of work, direct to your
computer, and no DHCP on either side - that way, there's only one place
your packet can go, so you on't have to worry about your switch/router
doing any funny stuff with it.


Article: 91736
Subject: Re: SDRAM controller.
From: "jai.dhar@gmail.com" <jai.dhar@gmail.com>
Date: 11 Nov 2005 06:12:43 -0800
Links: << >>  << T >>  << A >>
I am using the exact same RAM with Ateras SDRAM controller, which has
source with it. Are you doing this just for academic purposes? I would
suggest looking at their core, just because I know it works :)


Article: 91737
Subject: Re: Coolrunner output pins stuck at 0V
From: "jvdh" <johannes.vanderhorst@gmail.com>
Date: 11 Nov 2005 06:44:34 -0800
Links: << >>  << T >>  << A >>
Thaks for your 2 c :)

Unfortunately I currently only using combinatorial logic (output0 <=3D
input0;  output1 <=3D =B41=B4; output3 <=3D '0'; ), no clock yet, and no
logic that expects a clock...

Code is OK, is implemented the same program on my Spartan 3 fpga, works
as expected.

I found a 4 line post on the Xilinx state descibing one of the features
for a service pack as "(SP2) 7.1i CPLD Hprep6 XC9500/XL/XV CoolRunner
XPLA3 - Device (Jedec) does not function properly on the board (Xilinx
Answer 21168)", so I'm downloading the SP now, will try that out
later...

>> "when everything doesn't move, check the clock first..."
I like this - I'll use it in the next part of my design :)

johannes


Article: 91738
Subject: Factory Mutual Approvable Sealed Lead Acid Battery
From: "Eric" <ericjohnholland@hotmail.com>
Date: 11 Nov 2005 07:03:05 -0800
Links: << >>  << T >>  << A >>
This isn't a specific embedded or FPGA problem, but I'm hoping someone
has some advise.

Does anyone know of a 6V 12Ahr Sealed Lead Acid Battery that has been
able to pass FM's or ATEX short circuit temp. rise test?

I designed in a Diamec DM6-12, but when Factory Mutual was testing the
short circuit temperature rise of the battery within a few seconds the
battery becomes an open circuit and it has only raised 3 degrees C.
(There must be some mechanical fuse-able link inside) So they can't
actually test an internal cell short circuit fault from the outside of
the battery.

FM doesn't want to cut open the battery and actually test the internal
cells for heath risks, which I understand.

If you have any ideas on a new battery, that would help me out a lot.

Thanks

Eric


Article: 91739
Subject: Re: Signal timing problem
From: "motty" <tlassiter@rfmd.com>
Date: 11 Nov 2005 07:03:35 -0800
Links: << >>  << T >>  << A >>
Thanks guys.

But Andy, what is there to do when there is no F'in data sheet to read
(in scared )?  The part is a company internal ASIC on its first spin
and actually that spec is not a problem right now . I KNOW that there
is a delay associated with respect to when the external part presents
valid data after a rising edge of the clock it sees.  By the way, the
clock that all my synchronous logic is being driven from is 2x the
clock the external part sees.  The whole state machine is rising edge
driven from that clock.  The clock the external device sees is
generated in synchronous logic by that clock too.  I use the derived
clock's levels (not edges) internally to see when I need to clock data
out and clock data in.  Those specs (when data transitions) are
different depending on which company part I am writing/reading so it
HAS to be flexible.  Anyways, I digress....

I can monitor the delay from rising edge of the clock the part sees to
when data is valid.  I am looking at it on an o-scope.  No problem.
All setup times are WELL within margin.  The problem occurs somewhere
in the FPGA.  If I could sample the data at the external pins I am
looking at on the o-scope, then I would read back correctly ALL of the
time.  The FPGA works fine when we are NOT using the extender
board...the part is much closer to the FPGA.  When using the extension,
the read back data is incorrect.  Again, it looks fine on the o-scope
in BOTH cases.  In a simplified delay equation of:  total delay = delay
from part to FPGA pin + delay from FPGA pin to internal logic module, I
need to use the delay from FPGA pin to internal logic module as my
variable.  That is the value I need to tweak.

This is hard to make sense of in a forum without typing a document!
  
Thanks.


Article: 91740
Subject: Re: fastest possible USB
From: "johnp" <johnp3+nospam@probo.com>
Date: 11 Nov 2005 07:44:38 -0800
Links: << >>  << T >>  << A >>
We recently implemented a design that moved to a PC using USB 2.0

We used a Spartan3 coupled to a Cypress FX2 part and were able to
achieve
30MB/sec transfer rates.  It took careful driver development on the PC
to get the
performance level up high enough.

It was a fun project, but the Windows driver development took a lot
longer than
expected - it was tricky to get the performance up to where we needed
it.

John Providenza


Article: 91741
Subject: Re: open-sourced FPGA (vhdl, verilog, C variants) design libraries,
From: "Mike Treseler" <mike_treseler@comcast.net>
Date: Fri, 11 Nov 2005 08:08:07 -0800
Links: << >>  << T >>  << A >>
Martin Thompson wrote:

> Personally I'd love to get
> away from writing low-level VHDL for *some* of the things I do, but I
> wouldn't fancy writing an SDRAM controller in a C-like HDL either.

There is a middle ground already available
using standard vhdl synthesis that
doesn't cost a dime or a gate or a flop.

I use single process entities
with no signal declarations.
I declare process variables for every
local register and output port.
I use functions to create values
and procedures to collect and name
all repeated command sequences.

I use exactly this template of
three top procedures in every
new design entity:

    begin  -- process template
       if reset = '1' then
          init_all_regs;  -- no port init required
       elsif rising_edge(clock) then
          update_process_regs;
       end if;
       update_output_ports; -- wires ok for reset or clk
    end process template;

This style feels somewhat C-like but the
template keeps me in "think hardware" mode.

            -- Mike Treseler

Article: 91742
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: air_bits@yahoo.com
Date: 11 Nov 2005 08:26:48 -0800
Links: << >>  << T >>  << A >>

Martin Thompson wrote:
> I had a quick play the other day and I noticed that the counter
> example generates it's own set of lookup-tables for the increment
> logic, creating an enormous VHDL file.  I imagine the code generator
> could be simplified somewhat to take advantage of modern
> synthesis... writing a process with x:=x+1 in!

I had a similar experience and mind set for a while, but I'm not so
sure after spending a few hours hacking on the code to preserve
bit vector naming last spring. The VHDL netlist output is called after
all the optimizations have been done in FpgaC, and it more or less
then attempts to build the same circuit structures in VHDL that it
would in XNF.

Internally TMCC/FpgaC does not save statements while parsing, it
goes straight to building internal netlists for the operations. As a
result using FpgaC for a C to VHDL translator is more than a bit
of work and would radically interfer with the compiler C to netlist
functions. It would effectively require breaking FpgaC into two
parts, which would probably be better done by stripping the backend
off FpgaC and making a second tool for a C to VHDL translator
that would preserve statement level syntax.

Since the long term goal is to produce good XNF/EDIF netlists
that are tightly integrated to a set of RPM's and cores for
reconfigurable computing, it has not been clear if VHDL output
is the best way to get there, or a diversion.

>
> My personal wishes for it would be
>
> a) you can "simulate" the code with a suitable wrapper using a normal
> C-compiler

That is already the goal for FpgaC. I've already done some of this as
I've
hacked the original TMCC work. Implementing the rest of the C native
types, moving the port definitions to pragmas, and starting the move to
using bit field syntax is all part of that goal. The current bit field
size hack
isn't precise C, as FpgaC doesn't have structures. One of the next
changes
is to introduce structures, unions, and enums into Fpga so that bit
fields
in a structure will be the same as bit fields in standard C. Adding
some
pragmas which guide enum, counter, and state machine generation by
suggesting one-hot, grey coded, and traditional counter types is
somewhere
in the long term road map.

Typedef also needs to be added, but that will probably happen sooner as
we fix the symbol table scoping rules in the next group of changes that
will overhall the entire symbol dictionary code.

While other C to netlist tools are generally trying to make C an HDL,
and
are willing to make radical changes to the language departing from std
C,
I'm looking to target FpgaC as an HLL to netlist tool, less concerned
with
having it compete directly with VHDL/Verilog. The intent here is to
make
FpgaC a very good C to netlist tool for reconfigurable computing, which
preserves std C execution expectations on a traditional compiler and
cpu.

Thus, it should always simulate correctly on a cpu, unless you work
hard
to break it by using some HLL specirfic feature (if any remain), or the
word size choice in the netlist target can not be represented in the
CPU
you are simulating on and there are some word size or endan problems
as a result.

> b) you can explicitly parallelise stuff within a given function

This breaks a).

The goal is to do a) in the most parallel way that can be done
transparently.
Much as multiissue super scalar CPU's do .... IE exploit as much
parrelism
as exists in the sequential specification. This is actually quite a
bit, and
frequently much more than a super scalar processor can muster.

Currently, every statement block is allowed to become a flattened
combinatorial
netlist. So a single statement loop, doesn't have much parallism,
unless it's
a pretty complex statement with a lot of subexpression operations.
There we
win, as the entire expression can be flattened to a single
combinatorial net list.

Later to improve this I plan to add loop unrolling guided with a pragma
as a space
time tradeoff.

This doesn't break a), and preserves the ability to use a traditional
cpu as an
effective simulation environment.

> c) some form of communication is provided between processes, that also
> simulates in boggo-C.  Something like Occam channels or FSL ports
> would be my preference

In a traditional multiple processor environment, MPI and PVM provide
the
communications standards that are widely used. The intent is to create
some intrinsics that the compiler uses to build mailboxes and FIFO's
for
IPC needs, and then provide an FpgaC set of libraries and header files
that do most of std libc, MPI, PVM and posix-threads.

This addition to FpgaC is needed to handle PCI to host communications,
as
well as inter-FPGA communcations in multiple FPGA platforms.

Extending FpgaC in this way, preserves a).


Article: 91743
Subject: Re: Signal timing problem
From: "Mike Treseler" <mike_treseler@comcast.net>
Date: Fri, 11 Nov 2005 08:37:23 -0800
Links: << >>  << T >>  << A >>
motty wrote:

> By the way, the
> clock that all my synchronous logic is being driven from is 2x the
> clock the external part sees.  The whole state machine is rising edge
> driven from that clock.  The clock the external device sees is
> generated in synchronous logic by that clock too. 

For a synchronous interface to work properly without
a handshake, both ends need to see the clock rising
edge at exactly the same time. The only practical
way to do this for more than an inch or two is
use a zero-delay clock distribution chip and
wire equal length transmission lines from the chip
to the clock input at each end of the interface.
You have to cover both the normal and extended cases somehow.

Or add a handshake.
Or go source synchronous.
Or tune up the clock delay using the fpga PLL.

         -Mike Treseler

Article: 91744
Subject: Re: open-sourced FPGA (vhdl, verilog, C variants) design libraries, working toward a GNU (for hardware) paradigm
From: air_bits@yahoo.com
Date: 11 Nov 2005 08:38:16 -0800
Links: << >>  << T >>  << A >>

Mike Treseler wrote:
> This style feels somewhat C-like but the
> template keeps me in "think hardware" mode.

Yep. Then the big difference starts, debugging in "think hardware"
mode, or debugging in "think software" mode using source level
debuggers with break points, single stepping and variable watching
at a high level.


Article: 91745
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: air_bits@yahoo.com
Date: 11 Nov 2005 08:40:19 -0800
Links: << >>  << T >>  << A >>
I should add, that Chirag and I coulfd use help in realizing these
goals.


Article: 91746
Subject: Re: Factory Mutual Approvable Sealed Lead Acid Battery
From: Tim Wescott <tim@seemywebsite.com>
Date: Fri, 11 Nov 2005 08:53:03 -0800
Links: << >>  << T >>  << A >>
Eric wrote:

> This isn't a specific embedded or FPGA problem, but I'm hoping someone
> has some advise.
> 
> Does anyone know of a 6V 12Ahr Sealed Lead Acid Battery that has been
> able to pass FM's or ATEX short circuit temp. rise test?
> 
> I designed in a Diamec DM6-12, but when Factory Mutual was testing the
> short circuit temperature rise of the battery within a few seconds the
> battery becomes an open circuit and it has only raised 3 degrees C.
> (There must be some mechanical fuse-able link inside) So they can't
> actually test an internal cell short circuit fault from the outside of
> the battery.
> 
> FM doesn't want to cut open the battery and actually test the internal
> cells for heath risks, which I understand.
> 
> If you have any ideas on a new battery, that would help me out a lot.
> 
> Thanks
> 
> Eric
> 
Ask this question on sci.electronics.design -- it'll be seen by way more 
analog folks that way.

I, alas, do not approach that level of expertise with batteries.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Article: 91747
Subject: Re: open-sourced FPGA (vhdl, verilog, C variants) design libraries, working toward a GNU (for hardware) paradigm
From: air_bits@yahoo.com
Date: 11 Nov 2005 09:48:05 -0800
Links: << >>  << T >>  << A >>

Jim Granville wrote:
>   It would requires more of the designer, but what about a pragma like
> the ASM one, in many C's ? - it would accept VHDL (or verilog), and
> pass on to the downstream tools.
>   The advantage is it would understand the variable names, and scopes, of
> the other source ( much like in line asm does now ? ).
>   If a LOT of HDL code was needed, then separate code modules would be
> better.

That's a hard one, and I've considered it several times, then backed
off to
using perl post processing of the XNF.

My current feeling is that it's probably wrong to do this in FpgaC,
except
maybe for the XNF outputs. The real problem here is that any feature
such
as an ASM, probably needs to be reasonably respresentable in any of the
output forms for the net list. As we move from XNF to EDIF netlists, it
gets even more difficult, because small changes need to be reflected
into
several different portions of the EDIF output, where at least XNF is
pretty
linear in that respect, just as machine language statements would be
into
an assembler. To be truthful, to make ASM work, the logic optimizations
would have to be turned off, and the resulting netlist would get pretty
bloated. There would also have to be some specific hacks to make the
internal symbols visible, since there are not architecturally specified
resources like machine registers that ASM would target in a traditional
ISA machine.

The last arguement against it, is that it breaks the reason for making
FpgaC
as close to std C on a CPU/Memory, as the code is no longer directly
testable on a traditional programming platform. So from this
perspective
it's better to push things that don't directly fit the std C model,
into another
HDL (Celoxica-C, VHDL, Verilog) and debug those parts separately using
hardware simulators and hardware debuggers, and protect the ability to
debug the rest of the C HLL system with stubs for the hardware
interfaces
and use more efficient HLL debugging tools.

It would not suprise me to see one or more people fork FpgaC to become
an HDL for specific projects, or even take TMCC which was intended as
an HDL and similarly extend it. If it makes sense at some point, maybe
the FpgaC team will go ahead and do it, creating a second FpgaC_HDL
tool chain.

There is likely to always be this dual headed monster of is FpgaC an
HLL for reconfigurable computing, or an HDL for hardware design on
FPGA's? My perspective is that doing the HDL side right requires a
lot of optimizations for target FPGA's that are not particularly
general.
I believe it is possible to do FpgaC for reconfigurable computing uses
that is a lot more general, less tied to target FPGAs, and this is
the use that is not well supported by other HLL/HDL tools, paticularly
when you consider test and debugging and the relatively horrible mess
of using gate/timing simulators to debug HLL algorithms and multiple
threaded applications with communications.


Article: 91748
Subject: Re: Factory Mutual Approvable Sealed Lead Acid Battery
From: "Noway2" <no_spam_me2@hotmail.com>
Date: 11 Nov 2005 10:12:56 -0800
Links: << >>  << T >>  << A >>
Can you get some testing documentation from the battery company that
certifies that it meets the requirements?

I know that FM likes to do their own testing, but they may be willing
to accept data that proves that it meets their requirments, especially
if fault testing is hampered by a safety feature of the device and to
bypass it would be dangerous.


Article: 91749
Subject: Re: Factory Mutual Approvable Sealed Lead Acid Battery
From: "larwe" <zwsdotcom@gmail.com>
Date: 11 Nov 2005 10:27:23 -0800
Links: << >>  << T >>  << A >>

Eric wrote:
> Does anyone know of a 6V 12Ahr Sealed Lead Acid Battery that has been
> able to pass FM's or ATEX short circuit temp. rise test?

Umm... did we try google "factory mutual sla battery"?

Multiplier Industries Corp. - http://www.multiplier.com/
Manufactures rechargeable Ni-Cd, Ni-MH, Li-Ion and Factory Mutual
approved batteries custom packaged for the OEM.

But there are plenty of SLAs available, also try Rocket (Global &
Yuasa) and Casil (Chee Yuen) as I know these specific brands, among
others, are used in FM-listed fire panels.




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