[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[oc] Reset signals? Oh okay, Reset signals? Oh okay, Reset signals? Oh okay, Reset signals? Oh okay,



Martin,

<snip>

> For real, portable, synthesisable hardware you need a reset signal.  You
have got lucky
> (or read the Xilinx docs) in that the registers are defined to be zero
after configuration
> of the device, which is what you wanted.   If you for some reason want to
start in state
> 1 you'll not be able to do it like that... unless your Verilog synthesiser
understands the
> inital block and sorts out the register initialisation.  Either way, you
can;t then target
> an ASIC as they have no "intial configuration", so you will then need a
reset pin.  Are you
> pondering ASICs at all, or just FPGAs?

To be honest when I tried to get Webpack to assign any connections to the
"button" pin on my FPGAs
I received complete crap back as place and route errors. Just getting the
BUFG information to
get the stupid software to let me use any clock signal on the FPGA was agro
enough for me. What
can I say, I'm a programmer, I understand sequential logic better than
combinational.

My commercial products can be either ASICs or FPGAs. FPGAs are more
expensive (I know that much)
but if I release an update then I only have to supply them with a new SPROM
(hopefully) and job
done? ASICs are great for speed but you lose re-programmability as far as I
understand it. If its
going to be a 'cheap one' like say a new IDE controller then I'll ASIC it
but if its going to be
a reconfigurable Linux on a chip say then obviously FPGA will win out. Plus
I have no idea how much
it costs to get ASICs made, the pricing levels or anything of that sort so
I'll just leave that up
to the company I get to build my boards in the most part. Probably be around
8% of my projects would
be okay to use ASICs and the other 92% would have to FPGA for the
re-programming ability.

Thanks for the clock info but surely your clock, will maybe get to use it
for new C program tests. ;-)

Paul

--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml