--- In Catalin Ionescu <> wrote:
>
> Hi Michael,
>
> Thank you for your input! We decided to keep very tight control over the
> list of contributors to the wiki just to keep "noise" out of it. But I will
> add the information you have provided once it's clear to myself.
>
>
> First of all regarding the PCI pins, I know that in theory it's just the
> extra clamp diode, but those pins, when checked in EPIC Device Editor, seem
> to also be arrange a lot better for the idea of a bus. Right now there is no
> way you can have an FPGA design to be located close to PCI pins. You have 2
> pins on the top edge, 7 pins on the bottom edge and the rest on the left
> edge. Even the simplest address decoding requires signals to cross the whole
> matrix of slices.
Our PCI bus runs at 50Mhz on the TS-7800 and has gobs of margin to meet all
timing contraints at even 66Mhz. There was and is no need to pay any special
attention to I/O pad placement. There was and is no need to run our bus any
higher than 50Mhz as it is already overkill for the highest speed peripheral
(NAND flash).
A 50Mhz PCI bus can support approximately 200megabytes/sec of data. There was
no need for you to use a 60Mhz PCI bus in your design. You have removed safety
margin from the potential of your design by doing so. If your requirement was
simply acquiring samples of a 16-bit ADC @ 80Mhz to CPU SDRAM, we would
probably have quoted you 4-8 man-hours of work. (e.g. .5-1 day project, approx
$1200) Our 7800 FPGA implementation could have run 66Mhz with your core if we
needed to due to some unforseen deficiency in acheiving max predicted PCI
bandwidth @50Mhz. Usually, not even a company's internal engineering dept. can
compete with many of our quotes after considering their own salaries &
employment overhead.
>
> I'm working on a design that handles 160MB/s of data (16-bit, 80MHz ADC) and
> the PCI works at 60MHz. It's quite at the very limit that the FPGA can do
> with the current connections. My design works, but with extra registers to
> insure the delay doesn't exceed the high speed clock period. Just for fun, I
> have tried the same Verilog file with a .prf file to match an ideal PCI pins
> mapping. The speed difference wasn't that insignifiant because all PCI
> related stuff was strictly in the bottom quadrant of the FPGA.
>
> But what's done is done and we have to live with it! I'm glad that I have
> found a way of getting it working.
Internally, our FPGA runs a cross-bar 100Mhz WISHBONE fabric and has over
400MByte/s of bandwidth. IMHO, A proper design does not try to put large
combinational fanout logic on the PCI address decode starting from the pins so
I don't agree the layout needs workarounds to accomodate this slow HDL coding
style. On a slower FPGA architecture we have successfully run 100Mhz
200MByte/s SDRAM interfaces with ad-hoc pad placement. If I needed to move
pins to make timing, we could have done that easily -- there was just no need
at only 50-100Mhz. Inproper or lazily coded HDL -- well thats another story --
I can make even the simplest of logic run slow on extremely fast FPGA's by not
using proper pipelining and then blame the layout guy for not giving me the
fastest routing. Unfortunately, my boss (Bob Miller) is smarter than me and
wouldn't fall for that particular excuse why an otherwise easy design isn't
meeting timing constraints (esp. since he's also the layout guy!). Pipel
ining is not hard -- it comes naturally to hardware guys but requires an
unpleasant mental "leap" for pure software guys.
>
> As for the partition table thing, Alex has initially found out that kernels
> larger than 3MB can't be loaded by the MBR. And I hate the idea of initrd.
> So we started playing with the partition tables of both the NAND and the SD
> card and learned theor problems the hard way. Practically not all the space
> was used for the kernel and the initrd partition. At a given moment new MBRs
> have been uploaded on the FTP server and a binary comparision showed that
> just the partition tables have been modified. So we started playing with
> them.
>
> Right now we use 4Mb for kernel, I have dropped initrd completely, and we no
> longer have MBR related issues.
The initrd is optional. If there is no 2nd partition with ID "0xda" an initrd
and initrd ATAG won't be loaded for the kernel.
There is no reason that kernels larger than 3MByte cannot be loaded by the MBR.
Simply repartition with more space. We used the smallest possible space
because it minimizes bootup time. We anticipated those sophisticated enough to
compile their own custom kernels to be sophisticated enough to handle
repartitioning if their kernels ended up bigger.
> The other problem, with the correct ARM Machine ID for having proper support
> in mainline kernel, I have done it by looking into the binary of the MBR and
> searching for the value announced by a debug kernel that refused to load.
> And I have corrected it with a hex editor.
Sometimes it seems this whole ARM machine ID business is nothing more than a
control tactic Linux/ARM is trying to use on ARM embedded device vendors. We
will try to accomodate these quirky Linux'isms in future products, but not
because of any technical merit we see in the whole concept as recognized by the
engineering dept., but instead as a Technologic Systems public
relations/marketing requirement. BTW, Linux/PPC has no such ridiculous
requirement of the bootloader (machine ID and ATAG junk) -- the open-firmware
device tree can be embedded straight into the kernel and you're done -- a truly
self-contained embedded OS. Sometimes I wonder is Linux/ARM supposed to be a
standalone operating system or an application of the uBoot/RedBoot bloatware
where proper parameter passing should be obeyed? We figured the former and
since we weren't using uBoot/RedBoot we didn't pay much attention to what was
considered the "proper" machine ID.
>
>
> But now, with the source code of the partition table, we will put it on the
> wiki and, if you agree, also put there a binary version with correct machine
> ID.
This is okay by us. Its really a shame somebody went to the trouble
decompiling our 442 byte thumb MBR bootloader -- if you just called us up and
asked for it, we probably would have just given it to you.
//Jesse Off
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|