Каким образом получаеться нетлист у Coregen Опции

[Olxx]

Задался вопросом - есть Coregen, который может генерировать корки в виде нетлиста. Эти нетлисты могут генерится для разных типов плис с разными вариантами настроек и конфигураций. По идее - единственный вариант для генерации таких корок - это хранить исходники (пусть даже в зашифрованом виде) и при необходимости синтезировать нужный нетлист. Но в большинстве корок Ксилинкса (даже платных) исходники отсутствуют, но нетлист как-то генерится. Кто знает - как они умудряються нетлист синтезировать???

[makc]

Все очень просто. У них лежит набор нетлистов для различных архитектур. При распаковке нетлиста Coregen зная, какая архитектура кристалла используется в проекте, выбирает и распаковывает нужную.

[Olxx]

На первый взгляд - это логичное обьяснение. Но что делать если есть какая-нибудь DSPшная корка типа reed-slomon или viterbi с кучей конфигурационных параметров многие из которых могут существенно повлиять на архитектуру дизайна корки в целом. В этом случае, исходя из Вашей логики, необходимо держать огромное количество нетлистов для всех возможных комбинаций парамтеров корки, но этого явно не наблюдаеться.
Еще одно возможное обьяснение - у ксилинкса есть некий "параметризуемый" нетлист но это тоже крайне маловероятно из-за запредельной сложности в реализации подобного подхода.
Т.е. скорее всего исходники где-то должны быть, скорее всего спрятаные внутри *.class, т.е. лежат внутри java класов. Да и названия этих классов очень подходят под эту теорию.
Как Вы думаете - насколько это вероятно?

[makc]

На первый взгляд - это логичное обьяснение. Но что делать если есть какая-нибудь DSPшная корка типа reed-slomon или viterbi с кучей конфигурационных параметров многие из которых могут существенно повлиять на архитектуру дизайна корки в целом. В этом случае, исходя из Вашей логики, необходимо держать огромное количество нетлистов для всех возможных комбинаций парамтеров корки, но этого явно не наблюдаеться.

Да, для такого случая держать огромное количество нетлистов попросту невозможно. Если говорить, например, о RS-корках, то там лежит набор зашифрованных java-классов, которые отвечают за генерацию с заданными ранее параметрами edif-нетлиста. Который, кстати, тоже ложится в закрытом виде.

Еще одно возможное обьяснение - у ксилинкса есть некий "параметризуемый" нетлист но это тоже крайне маловероятно из-за запредельной сложности в реализации подобного подхода.

А как вообще нетлист может быть параметризуемым? Может быть, в принципе, некоторый шаблон нетлиста. Да и то это очень сложно и трудно реализуемо. Так что параметризуемых нетлистов там точно нет.

Т.е. скорее всего исходники где-то должны быть, скорее всего спрятаные внутри *.class, т.е. лежат внутри java класов. Да и названия этих классов очень подходят под эту теорию.
Как Вы думаете - насколько это вероятно?

Исходников там, смею Вас заверить, нет. Однако эти классы обеспечивают генерацию требуемого нетлиста. При этом сам CoreGen, на сколько я понимаю, очень тесно участвует в этом процессе. Если интересно, то запустите coregen -d. После этого на диске появится файл coregen.log, из которого можно почерпнуть для себя довольно много интересного.