( ESNUG 387 Item 14 ) -------------------------------------------- [01/23/02]
Subject: ( ESNUG 386 #16 ) BSD Compiler Is Getting Better In Fits & Starts
> I wouldn't call it perfect as of yet, but BSD Compiler works and it is now
> automated enough that a even co-op student can use it in our design flow.
>
> - Shin Wu, ASIC Division
> Atmel Corporation Columbia, MD
From: [ The Cat In The Hat ]
Hi, John,
We, too, use BSD Compiler for JTAG insertion on our ASICs and have had our
share of problems. I thought I might share some comments and, if you don't
mind, ask some questions. I must remain anonymous here.
> 1.) BSD Compiler was not able to insert Boundry Scan with the design core
> in the netlist, contrary to BSD Compiler User Guide's claims. We
> overcome this by removing the core before inserting Boundry Scan.
I did not try to run the insertion with the full core. I used a core shell
module to speed up the compile time. For simulation, I used assigns for
driven/driving ports in the core.
> 2.) There was the problem of not being able to pass the simulations with
> the vectors generated by BSD Compiler to verify synthesized 1149.1
> components. We overcome this by breaking up vectors to verify
> individual components, such as TAP, BSR, TDR and reset mechanism.
> Somehow vectors generated this way did not have any problems in
> simulations.
What tests in particular failed when run as a whole?
I did not see any problems, but then I am not sure that I have covered
everything as there doesn't seem to be any fault coverage type numbers
to be had.
> 3.) BSD Compiler had problems with our Synopsys Atmel libraries as well.
> It could not synthesize functional 1149.1 components when input
> buffers supported both true and complementary outputs going into the
> array. It couldn't implement the HIGHZ instruction with bidi buffers.
We are having trouble getting BSD to verify our LVDS pad. When running
check_bsd, the tool complains about the pad having no path from a-to-y. We
are using TI as a vendor. The pad works fine in simulation, but the tool
cannot seem to work with it. In order to go on to generate BSDL and test
vectors, I have to replace the LVDS with dummy non-differential pads to get
past check_bsd. Our Synopsys AE is working on finding a solution.
Unfortunately, BSD Compiler does not have as much visibility as Design
Compiler or PrimeTime.
Do you have any problems with differential input pads, or ones that have
power-down inputs and float outputs?
Our bidirectional pads work okay if one is careful about how they handle
the tristate control pin on the output pad cell. The tool needs to be
able to control the tristate control pin from the tap for the HIGHZ test
to work.
The tool also cannot support multi-channel pad modules, such as those
used in highspeed interfaces. We are using SERDES modules which have up
to eight-channels and the tool cannot interpret their function. I had to
create dummy pad cell arrays to do the JTAG insertion and then restore
the SERDES modules afterwards. I have asked them to support these modules
in future releases and they said they would try, but no real commitment.
I am presently using 2001.08-SP1 on the advice of my Synopsys AE.
Anyway, just thought I would share my experiences and hopefully the ESNUG
readers can help with my BSD Compiler questions.
- [ The Cat In The Hat ]
---- ---- ---- ---- ---- ---- ----
From: "Gregg Lahti" <gregg.lahti@corrent.com>
Hi, John,
I had the opportunity to use BSD Compiler on our last chip. I agree with
Shin Yuan Wu that BSD Compiler is usable and getting better. Some things
that I found that made life more interesting using the 2001-08 rev of
BSD Compiler:
1) Insertion of Boundary Scan with the core wasn't an option. We built a
dummy of the core module for it to work on instead. We also had issues
with our pad cells, where we used RTL-style models for functionality in
the BSD test bench creation. Unfortunately, BSD Compiler also included
the guts-level functionality modules of the pad cells in the output
Verilog netlist. A minor tweak which corrected this problem was to
remove all pad designs before we wrote out the Verilog.
2) Convincing BSD Compiler to not insert MUXing in the input path
(observe-only function) wasn't as clear cut as it could have been. Even
though I specified the type 4 input Boundary Scan cells to use, BSD
Compiler wouldn't use them unless I specified a huge input delay to
"persuade" the tool to use the correct type of Boundary Scan cells.
This behavior is spelled out in one page of the docs, but jumping
through this hoop seems redundant and somewhat broken, IMHO.
3) I had a case somewhere in the debugging of #2 where setting:
set_fix_multiple_port_nets -all -buffer_constants
wasn't being honored to not include assign statements in the Verilog.
Of course this is a kludge to fix the real issue of Apollo's crappy
netlist reader, but it still caused me to hand-insert buffers on nets
so I could get the netlist into layout. At some point while fixing #2
and replacing the type-2 & type-7 cells with type-4 cells, the problem
vanished.
4) It would be a nice feature in BSD Compiler to allow multiple TAP
controllers. It wasn't clear how we could achieve this using BSD
Compiler, so we built a separate muxing block to route the JTAG
pins appropriately to the second TAP controller in our block for our
embedded uP's.
My local AE (Taimei DeZeeuw) and the San Diego AE (Robert Moussavi) spent
some time helping us get the initial scripts in place which got us going
pretty quickly and saved us from initial headaches. Overall, BSD Compiler
worked as expected and provided a test bench which worked well. Some
minor annoyances were found, but it did the job and didn't cause me to
lose too much sleep in the process of using it.
- Gregg Lahti
Corrent Corp. Tempe, AZ
|
|
