Index of /~dst/DeCSS/Gallery/Bybell

      Name                    Last modified       Size  Description

[DIR] Parent Directory 04-Jan-2003 01:19 - [   ] CSSTAB1.abel 05-Apr-2001 20:20 1k [   ] CSSTAB2.abel 05-Apr-2001 20:21 1k [   ] CSSTAB3.abel 05-Apr-2001 20:53 1k [   ] CSSTAB4.abel 05-Apr-2001 20:21 1k [   ] CSSTAB5.abel 05-Apr-2001 20:21 1k [   ] t.v 05-Apr-2001 21:00 3k [TXT] tables_generated.txt 05-Apr-2001 20:56 5k [   ] tables_verilog.tgz 14-Apr-2001 03:45 5k

Professor Touretzky,

The Verilog implementations of DeCSS on your webpage all suffer from very
large ROM tables which would be quite inefficient in a "real"
implementation because of chip real estate, address decoder latency, etc.
I decided to see how much the tables would compress if for example I were
tasked to do an ASIC implementation by my employer...

CSSTable 1: 22 gates [14 if optimized]
CSSTable 2:  7 gates  [5 if optimized]
CSSTable 3:  0 gates
CSSTable 4:  0 gates
CSSTable 5:  8 gates  [0 if absorbed into preceeding logic stage]

I find this interesting because it shows that the "tables" were carefully
designed with hardware implementation in mind and not as an afterthought.
As such, it wouldn't shock me if the rest of the algorithm is easily
modified into RTL either. Since the tables are used multiple times in the
algorithm, instantiating them in an RTL implementation doesn't cause a
large gate count since they're so trivial to implement--two of those
tables are zero cost!  Furthermore, most of the logic ops in Table 1 have
complemented outputs which come free in CMOS.  So the gate count is even
lower: 14 for Table 1.  That yields a grand total of 29 gates if one
wishes to instantiate each table exactly once, and 21 gates total if Table
5 can be folded into its feeder gate outputs.  If that weren't enough, two
of the XOR2s in Table2 can be represented as XOR3 gates, which brings the
count down to 19 gates.  Sadly, there are no AO/OA/AOI/OAI optimizations
to rub even more salt into the wound...

It's "the incredible shrinking trade secret" in more ways than one.

The .v file for the synthesizable structural modules is in the attached
tgz file.  In addition, I "synthesized" the tables as ABEL files (using my
own open source tools found at http://linux-workshop.com/bybell/ver) and
enclosed those ABEL files too.  Finally, the lone text file is for
verification purposes and is the output of running the testbench through a
suitable Verilog compiler that can handle behaviorals such as the open
source one at http://www.icarus.com.

Regards,
Tony Bybell